Re: pg_standby -l might destory the archived file
От | Tom Lane |
---|---|
Тема | Re: pg_standby -l might destory the archived file |
Дата | |
Msg-id | 16657.1243968861@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pg_standby -l might destory the archived file (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: pg_standby -l might destory the archived file
Re: pg_standby -l might destory the archived file |
Список | pgsql-hackers |
Heikki Linnakangas <heikki.linnakangas@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. regards, tom lane
В списке pgsql-hackers по дате отправления: