Hi, On Wed, Jun 3, 2009 at 3:54 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> writes: >> Tom Lane wrote: >>> That's a good point; don't we recover files under names like >>> RECOVERYXLOG, not under names that could possibly conflict with regular >>> WAL files? > >> Yes. But we rename RECOVERYXLOG to 000000010000000000000057 or similar >> at the end of recovery, in exitArchiveRecovery(). > >> Thinking about this some more, I think we should've changed >> exitArchiveRecovery() rather than RemoveOldXlogFiles(): it would be more >> robust if exitArchiveRecovery() always copied the last WAL file rather >> than just renamed it. It doesn't seem safe to rely on the file the >> symlink points to to be valid after recovery is finished, and we might >> write to it before it's recycled, so the current fix isn't complete. > > Hmm. I think really the reason it's coded that way is that we assumed > the recovery command would be physically copying the file from someplace > else. pg_standby is violating the backend's expectations by using a > symlink. And I really doubt that the technique is saving anything, since > the data has to be read in from the archive location anyway. > > I'm leaning back to the position that pg_standby's -l option is simply a > bad idea and should be removed.
I'm OK with this. And, we should document the assumption for restore_command? Otherwise, some users might wrongly use 'ln' command to restore archived files. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
