Re: [BUG?] lag of minRecoveryPont in archive recovery
От | Fujii Masao |
---|---|
Тема | Re: [BUG?] lag of minRecoveryPont in archive recovery |
Дата | |
Msg-id | CAHGQGwEUpEvK=s0xRFinWnoasjhy3poD3HiE4namoWHK0a-d_w@mail.gmail.com обсуждение исходный текст |
Ответ на | [BUG?] lag of minRecoveryPont in archive recovery (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>) |
Ответы |
Re: [BUG?] lag of minRecoveryPont in archive recovery
|
Список | pgsql-hackers |
On Thu, Dec 6, 2012 at 1:04 PM, Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> wrote: > diff --git a/src/backend/catalog/storage.c b/src/backend/catalog/storage.c > index 993bc49..d34ab65 100644 > --- a/src/backend/catalog/storage.c > +++ b/src/backend/catalog/storage.c > @@ -519,6 +519,12 @@ smgr_redo(XLogRecPtr lsn, XLogRecord *record) > visibilitymap_truncate(rel, xlrec->blkno); > > FreeFakeRelcacheEntry(rel); > + > + /* > + * Xlogs before this record is unrepeatable, so winding > + * minRecoveryPoint to here. > + */ > + XLogFlush(lsn); > } > else > elog(PANIC, "smgr_redo: unknown op code %u", info); I think that minRecoveryPoint should be updated before the data-file changes, so XLogFlush() should be called before smgrtruncate(). No? Regards, -- Fujii Masao
В списке pgsql-hackers по дате отправления: