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 <tgl@sss.pgh.pa.us> wrote:
> Brian Weaver <cmdrclueless@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 */
