Re: Unarchived WALs deleted after crash
От | Heikki Linnakangas |
---|---|
Тема | Re: Unarchived WALs deleted after crash |
Дата | |
Msg-id | 511E73AC.2070907@vmware.com обсуждение исходный текст |
Ответ на | Re: Unarchived WALs deleted after crash (Fujii Masao <masao.fujii@gmail.com>) |
Ответы |
Re: Unarchived WALs deleted after crash
|
Список | pgsql-hackers |
On 15.02.2013 19:16, Fujii Masao wrote: > On Sat, Feb 16, 2013 at 2:07 AM, Heikki Linnakangas > <hlinnakangas@vmware.com> wrote: >> On 15.02.2013 18:10, Fujii Masao wrote: >>> >>> At least in 9.2, when the archived file is restored into pg_xlog, its >>> xxx.done >>> archive status file is created. So we don't need to check >>> InArchiveRecovery >>> when deleting old WAL files. Checking whether xxx.done exists is enough. >> >> Hmm, what about streamed WAL files? I guess we could go back to the pre-9.2 >> coding, and check WalRcvInProgress(). But I didn't actually like that too >> much, it seems rather random that old streamed files are recycled when wal >> receiver is running at the time of restartpoint, and otherwise not. Because >> whether wal receiver is running at the time the restartpoint happens has >> little to do with which files were created by streaming replication. With >> the right pattern of streaming files from the master, but always being >> teporarily disconnected when the restartpoint runs, you could still >> accumulate WAL files infinitely. > > Walreceiver always creates .done file when it closes the > already-flushed WAL file > and switches WAL file to next. So we also don't need to check > WalRcvInProgress(). Ah, I missed that part of the patch. Okay, agreed, that's a better fix. I committed your forward-port of the 9.2 patch to master, reverted my earlier fix for this bug, and simply removed the InArchiveRecovery/ArchiveRecoveryInProgress()/RecoveryInProgress() condition from RemoveOldXlogFiles(). - Heikki
В списке pgsql-hackers по дате отправления: