Re: [9.3 bug] disk space in pg_xlog increases during archive recovery
От | MauMau |
---|---|
Тема | Re: [9.3 bug] disk space in pg_xlog increases during archive recovery |
Дата | |
Msg-id | 3AB3A05BACF5430F83802BA56BE05AD3@maumau обсуждение исходный текст |
Ответ на | Re: [9.3 bug] disk space in pg_xlog increases during archive recovery (Fujii Masao <masao.fujii@gmail.com>) |
Ответы |
Re: [9.3 bug] disk space in pg_xlog increases during
archive recovery
|
Список | pgsql-hackers |
From: "Fujii Masao" <masao.fujii@gmail.com> > ! 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? Oh, you are correct. Okay, done. > ! /* > ! * 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. That's already done in the previous patch: deletion of RECOVERYXLOG was moved into else clause, as in: - /* - * Since there might be a partial WAL segment named RECOVERYXLOG, get rid - * of it. - */ - snprintf(recoveryPath, MAXPGPATH, XLOGDIR "/RECOVERYXLOG"); - unlink(recoveryPath); /* ignore any error */ - Regards MauMau
Вложения
В списке pgsql-hackers по дате отправления: