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

Поиск
Список
Период
Сортировка
От Bossart, Nathan
Тема Re: archive status ".ready" files may be created too early
Дата
Msg-id E65B47AA-C50B-4AD7-A90B-25D106582EB8@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/18/21, 4:47 PM, "alvherre@alvh.no-ip.org" <alvherre@alvh.no-ip.org> wrote:
> On 2021-Aug-18, Bossart, Nathan wrote:
>> In the attached patch, I modified XLogInsertRecord() to simply set the
>> latch if we detect that flushRecPtr has advanced.
>
> Right, that's what I was thinking.  I modified that slightly to use
> LogwrtResult.Flush (which should be fresh enough) instead of calling
> GetFlushRecPtr again, which saves a bit.  I also changed it to > instead
> of >=, because if I understand you correctly we only care to notify if
> the flush pointer advanced, not in the case it stayed the same.

My thinking was that we needed to read flushRecPtr after registering
the boundary in case it advanced just before registration.  And I used
>= because if flushRecPtr points to the end of the record, we should
be able to create the .ready file for the segment.

We can avoid acquiring the spinlock an extra time if we move the first
part of the cross-segment logic to before we update the local copy of
LogwrtResult.  I attached a new version of the patch that does this.

The rest looks good to me.

Nathan


Вложения

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

Предыдущее
От: Julien Rouhaud
Дата:
Сообщение: Re: support for windows robocopy in archive_command and restore_command
Следующее
От: Tom Lane
Дата:
Сообщение: Re: strange case of "if ((a & b))"