Tom, I'm fine with submitting highly focused patches first. I was just explaining my end-goal. Still I will need time to patch, compile, and test before submitting so you're not going to see any output from me for a few days. That's all assuming my employer can leave me alone long enough to focus on a single task. I'm far too interrupt driven at work.
-- Brian On Tue, Sep 25, 2012 at 10:30 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Brian Weaver <cmdrcluel...@gmail.com> writes: >> If you're willing to wait a bit on me to code and test my extensions >> to pg_basebackup I will try to address some of the deficiencies as >> well add new features. > > I think it's a mistake to try to handle these issues in the same patch > as feature extensions. If you want to submit a patch for them, I'm > happy to let you do the legwork, but please keep it narrowly focused > on fixing file-format deficiencies. > > The notes I had last night after examining pg_dump were: > > magic number written incorrectly, but POSIX fields aren't filled anyway > (which is why tar tvf doesn't show them) > > checksum code is brain-dead; no use in "lastSum" nor in looping > > per spec, there should be 1024 zeroes not 512 at end of file; > this explains why tar whines about a "lone zero block" ... > > Not sure which of these apply to pg_basebackup. > > As far as the backwards compatibility issue goes, what seems like > a good idea after sleeping on it is (1) fix pg_dump in HEAD to emit > standard-compliant tar files; (2) fix pg_restore in HEAD and all back > branches to accept both the standard and the incorrect magic field. > This way, the only people with a compatibility problem would be those > trying to use by-then-ancient pg_restore versions to read 9.3 or later > pg_dump output. > > regards, tom lane -- /* insert witty comment here */ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
