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)
Список
Дерево обсуждения
[BUG?] lag of minRecoveryPont in archive recovery Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
Re: [BUG?] lag of minRecoveryPont in archive recovery Amit Kapila <amit.kapila@huawei.com>
Re: [BUG?] lag of minRecoveryPont in archive recovery Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
Re: [BUG?] lag of minRecoveryPont in archive recovery Amit Kapila <amit.kapila@huawei.com>
Re: [BUG?] lag of minRecoveryPont in archive recovery Fujii Masao <masao.fujii@gmail.com>
Re: [BUG?] lag of minRecoveryPont in archive recovery Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
Re: [BUG?] lag of minRecoveryPont in archive recovery Heikki Linnakangas <hlinnakangas@vmware.com>
Re: [BUG?] lag of minRecoveryPont in archive recovery Heikki Linnakangas <hlinnakangas@vmware.com>
Re: [BUG?] lag of minRecoveryPont in archive recovery Fujii Masao <masao.fujii@gmail.com>
Re: [BUG?] lag of minRecoveryPont in archive recovery Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
Re: [BUG?] lag of minRecoveryPont in archive recovery Heikki Linnakangas <hlinnakangas@vmware.com>
Re: [BUG?] lag of minRecoveryPont in archive recovery Fujii Masao <masao.fujii@gmail.com>
Re: [BUG?] lag of minRecoveryPont in archive recovery Heikki Linnakangas <hlinnakangas@vmware.com>
Re: [BUG?] lag of minRecoveryPont in archive recovery Heikki Linnakangas <hlinnakangas@vmware.com>
Re: [BUG?] lag of minRecoveryPont in archive recovery Fujii Masao <masao.fujii@gmail.com>
On Thu, Dec 6, 2012 at 1:04 PM, Kyotaro HORIGUCHI 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 по дате отправления