Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation()

Поиск
Список
Период
Сортировка
От Pavan Deolasee
Тема Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation()
Дата
Msg-id CABOikdNEj6zTRdKy3eyxn_-1_PgoxRFGFEkccSy1iQ-30Xdp0A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Changing WAL Header to reduce contention duringReserveXLogInsertLocation()  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation()  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Дерево обсуждения


On Wed, Mar 28, 2018 at 7:36 AM, Michael Paquier <michael@paquier.xyz> wrote:
On Tue, Mar 27, 2018 at 02:02:10PM -0400, Tom Lane wrote:

>
> Well, the point of checkpoints is that WAL data before the last one
> should no longer matter anymore, isn't it?

I have to agree with Tom here.  If you force pg_rewind to replay more
WAL records from a checkpoint older than the checkpoint prior to where
WAL has forked at promotion then you have a risk of losing data.

Yeah, we should not do that. The patch surely does not intend to replay any more WAL than what we do today. The idea is to just use a different mechanism to find the prior checkpoint. But we should surely find the latest prior checkpoint. In the rare scenario that Tom showed, we should just throw an error and fix the patch if it's not doing that already.

Thanks,
Pavan

--
 Pavan Deolasee                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: PostgreSQL crashes with SIGSEGV