Differences between revisions 29 and 35 (spanning 6 versions)
Revision 29 as of 2008-02-29 06:31:35
Size: 5115
Editor: arta-lt
Comment:
Revision 35 as of 2009-04-08 09:04:34
Size: 455
Editor: phil
Comment:
Deletions are marked like this. Additions are marked like this.
Line 5: Line 5:
[#status_jennifer Jennifer's] [:JennifersProgress#mostrecent:Jennifer's]
Line 7: Line 7:
[#status_jim Jim's] [:JimsProgress#mostrecent:Jim's]
[[BR]]
[:KarensProgress#mostrecent:Karen's]
Line 9: Line 11:
[#status_karen Karen's] [:Phil'sProgress#mostrecent:Phil's]
[[BR]]
[:RicksProgress#mostrecent:Rick's]
Line 11: Line 15:
[#status_phil Phil's]
[[BR]]
[#status_tim Tim's]

 . [[Anchor(status_jennifer)]]
=== Jennifer's archive ===
----
 - 02-28-2008
 * Created test plan for creating warm standby machine and breaking warm standby machine
 * Created test plan for implementing Slony-1 (and breaking Slony-1)
 * Followed first steps of plans:
     - Start & stop server: learned that without a WAL file containing a checkpoint, the database will not recover w/out pgresetxlog.
     - Start & stop server: moved WAL files to different directories, did not preserve file times, database still recovered
     - Start & stop server: removed last WAL file from tree, broke database server. Researched why to learn that it's all about checkpoints.
     - Start & stop server: copy WAL files to separate locations, recover successfully from each location (database did not have knowledge of other file locale).
 * Slony database successfully set up and working between tucano and equinox.
     - Security learning required before Slony-1 could be set up. Found out we are running md5 security (with .pgpass files) but that Postgres supports SSL. Also learned that Postgres is more intimately tied up with IDs in the Linux OS than some other database platforms. User postgres on equinox is completely independent of user postgres on tucano, making identification between the two servers more difficult.
 * More progress made on this test plan, please read ~jennifer/database/wal_testplans.txt
-----
 . [[Anchor(status_jim)]]
=== Jim's archive ===
----
 . 02-28-2008
 * DDS-SOC testing continues. All data is sent to pipeline backend (d00) and archived to the T50 tapes. The T50 tapes are being recycled as they are filled. Running successfully on both hmi dsc1 and aia dcs2.
 * Started program store_dsds_2_drms that queries the dsds for the given ds and ingests it into DRMS.
 * Started t950view which is the gui for display/control of the Spectra Logic T950 robot.
 * Upgrade of cvs/jsoc to cvs/JSOC. Ready to test the SUMS in the new tree.
 * Work on egse program to fix partial image bug and convert the program to execute a seperate instance for each primary VC.
 * Review of update DDS-SOC ICD. Must now upgrade the dcs machines to conform.
 * Continuing the 'real' lev0 module development
 
-----
 . [[Anchor(status_karen)]]
=== Karen's archive ===
----
. 02-28-2008

  * Phil helped me to gain more understanding of his naming document. In a dataset name, if none but ?? query exists, then we don't filter the latest version. I am looking into implementing this. I don't feel very comfortable with dataset names that involves multiple series, separated by commas. I am afraid some places are going to break. I am planning some tests.

  * Did rather laborious work to change owner/permission for namespace mdi from rick to dsdsdata. In particular, ownership change involves ALTER TABLE which requires an ExclusiveLock on the table. All of our running modules use AccessShareLocks on the master tables drms_*, hence they can block such ownership change. Another reason not to have long running transactions.

  * Worked with Art and Jim to fix a memory problem in sum_open.c. The problem has to do with freeing the memory that stores wd. sum_close() is not the place to free this memory. This is because between each pair of sum_open() and sum_close(), there will be a number of sum_get(), each of them allocates new memory. The proper place to free this memory is after sum_get() by any program that calls it, be it DRMS or not.

  * Merged in code for new "DBIndex" in jsd. "DBIndex" follows exactly the same syntax as "Index" (for specifying prime key).The max number of prime keys is set to 15 and max number of db indexed keyword is 10. For backward compatibility, when "DBIndex" is missing in a jsd, if the number of prime keys is no more than 5, then we create a composite index for all prime keys. This is the only case we'd create a composite index. Note it's legal for "DBIndex" to stand by itself without any keyword, no index will be created in that case.

  * Writing documentation
-----
 . [[Anchor(status_phil)]]
=== Phil's archive ===
----

-----
 . [[Anchor(status_tim)]]
=== Tim's archive ===
 * Read drms_fits.c to see how to pass parameters to/from cfitsio. A great portion drms_fits.c maybe no longer needed, so we will try to call cfitsio.c directly drms_segment.c.
 * Met with Art to for cvs checkin location. Art will create the make file for cfitsio for different types of builds.
 * Note: The C library from HEASARC called "fitsio", cfitsio is our wrapper.
 * We decide to remove a small header at the beginning of the data block, containing the basic info (naxis, naxes, bitpix,...) These info will be made available by caller function.
 * Try to combine writing and compressing to file into one step for efficiency
------

-----
[:TimsProgress#mostrecent:Tim's]
[[BR]]
[http://tenerife.tuc.noao.edu/blogs/logbook/hmijsoc/logbook/ Igor's Logbook]

JsocWiki: DeveloperProgressReports (last edited 2013-05-11 04:46:37 by ArtAmezcua)