On Mon, Dec 16, 2013 at 9:22 PM, MauMau <maumau...@gmail.com> wrote: > Hi, Fujii san, > >> On Wed, Aug 7, 2013 at 7:03 AM, Fujii Masao <masao.fu...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
