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

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation()
Дата
Msg-id CA+TgmoZMbPgU6VGG311UU0CLj0XO9-kSnLG+_6OH+it1_Sm=rg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation()  (Simon Riggs <simon@2ndquadrant.com>)
Ответы Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation()
Список pgsql-hackers
On Thu, Feb 1, 2018 at 7:21 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> Yes, it would be about 99% of the time.
>
> But you have it backwards - we are not assuming that case. That is the
> only case that has risk - the one where an old WAL record starts at
> exactly the place the latest one stops. Otherwise the rest of the WAL
> record will certainly fail the CRC check, since it will effectively
> have random data in it, as you say.

OK, I get it now.  Thanks for explaining.  I think I understand now
why you think this problem can be solved just by controlling the way
we recycle segments, but I'm still not sure if that can really be made
fully reliable.  Michael seems concerned about what might happen after
multiple recyclings, and Tom has raised the issue of old data
reappearing after a crash.

I do agree that it would be nice if we could make it work - saving 8
bytes per WAL record would be significant.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Query running for very long time (server hanged) with parallel append
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] Bug in to_timestamp().