Re: [9.3 bug] disk space in pg_xlog increases during archive recovery
От | Fujii Masao |
---|---|
Тема | Re: [9.3 bug] disk space in pg_xlog increases during archive recovery |
Дата | |
Msg-id | CAHGQGwFssgNTnAs=YOmF0di1V6EgwWHCovFbuVUFRs09SsbZEA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [9.3 bug] disk space in pg_xlog increases during archive recovery ("MauMau" <maumau307@gmail.com>) |
Ответы |
Re: [9.3 bug] disk space in pg_xlog increases during archive recovery
|
Список | pgsql-hackers |
On Mon, Dec 16, 2013 at 9:22 PM, MauMau <maumau307@gmail.com> wrote: > Hi, Fujii san, > >> On Wed, Aug 7, 2013 at 7:03 AM, Fujii Masao <masao.fujii@gmail.com> wrote: >>> >>> On second thought, probably we cannot remove the restored WAL files early >>> because they might be required for fast promotion which is new feature in >>> 9.3. >>> In fast promotion, an end-of-recovery checkpoint is not executed. After >>> the end >>> of recovery, normal online checkpoint starts. If the server crashes >>> before such >>> an online checkpoint completes, the server needs to replay again all the >>> WAL >>> files which it replayed before the promotion. Since this is the crash >>> recovery, >>> all those WAL files need to exist in pg_xlog directory. So if we remove >>> the >>> restored WAL file from pg_xlog early, such a crash recovery might fail. >>> >>> So even if cascade replication is disabled, if standby_mode = on, i.e., >>> fast >>> promotion can be performed, we cannot remove the restored WAL files >>> early. > > > Following Fujii-san's advice, I've made the attached patch. Thanks for the patch! ! if (source == XLOG_FROM_ARCHIVE && StandbyModeRequested) Even when standby_mode is not enabled, we can use cascade replication and it needs the accumulated WAL files. So I think that AllowCascadeReplication() should be added into this condition. ! snprintf(recoveryPath, MAXPGPATH, XLOGDIR "/RECOVERYXLOG"); ! XLogFilePath(xlogpath, ThisTimeLineID, endLogSegNo); ! ! if (restoredFromArchive) Don't we need to check !StandbyModeRequested and !AllowCascadeReplication() here? ! /* ! * If the latest segment is not archival, but there's still a ! * RECOVERYXLOG laying about, get rid of it. ! */ ! unlink(recoveryPath); /* ignore any error */ The similar line exists in the lower side of exitArchiveRecovery(), so ISTM that you can refactor that. Regards, -- Fujii Masao
В списке pgsql-hackers по дате отправления: