From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Brian Weaver <cmdrclueless(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Patch: incorrect array offset in backend replication tar header |
Date: | 2012-09-25 14:30:59 |
Message-ID: | 18775.1348583459@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Brian Weaver <cmdrclueless(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Devrim GÜNDÜZ | 2012-09-25 14:36:54 | pg_upgrade does not completely honor --new-port |
Previous Message | Tom Lane | 2012-09-25 14:23:47 | Re: Oid registry |