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 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 по дате отправления
От: Fujii Masao
Дата:
От: Simon Riggs
Дата:
FAQ