Re: archive status ".ready" files may be created too early

Поиск
Список
Период
Сортировка
От Bossart, Nathan
Тема Re: archive status ".ready" files may be created too early
Дата
Msg-id 4268438D-343C-4831-8511-17B03CEA028E@amazon.com
обсуждение исходный текст
Ответ на Re: archive status ".ready" files may be created too early  ("alvherre@alvh.no-ip.org" <alvherre@alvh.no-ip.org>)
Ответы Re: archive status ".ready" files may be created too early  ("alvherre@alvh.no-ip.org" <alvherre@alvh.no-ip.org>)
Список pgsql-hackers
On 8/23/21, 9:33 AM, "alvherre@alvh.no-ip.org" <alvherre@alvh.no-ip.org> wrote:
> On 2021-Aug-23, Bossart, Nathan wrote:
>
>> Hm.  My expectation would be that if there are no registrations, we
>> cannot create .ready files for the flushed segments.  The scenario
>> where I can see that happening is when a record gets flushed to disk
>> prior to registration.  In that case, we'll still eventually register
>> the record and wake up the WAL writer process, which will take care of
>> creating the .ready files that were missed earlier.  Is there another
>> case you are thinking of where we could miss registration for a cross-
>> segment record altogether?
>
> I'm thinking of the case where no record cross segment boundaries ever.

Sorry, I'm still not following this one.  If we skipped creating
.ready segments due to a crash, we rely on RemoveOldXlogFiles() to
create them as needed in the end-of-recovery checkpoint.  If a record
fits perfectly in the end of a segment, we'll still register it as a
boundary for the next segment (hence why we use XLByteToSeg() instead
of XLByteToPrevSeg()).  If database activity stops completely, there
shouldn't be anything to mark ready.

Nathan


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

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: pretty slow merge-join due rescan?
Следующее
От: "alvherre@alvh.no-ip.org"
Дата:
Сообщение: Re: archive status ".ready" files may be created too early