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

Поиск
Список
Период
Сортировка
От Bossart, Nathan
Тема Re: archive status ".ready" files may be created too early
Дата
Msg-id 997F25DB-5D57-4FB1-BA97-6110D8BF1415@amazon.com
обсуждение исходный текст
Ответ на Re: archive status ".ready" files may be created too early  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Ответы Re: archive status ".ready" files may be created too early
Список pgsql-hackers
On 7/31/21, 9:12 AM, "Alvaro Herrera" <alvherre@alvh.no-ip.org> wrote:
> On 2021-Jul-31, Bossart, Nathan wrote:
>
>> On 7/30/21, 4:52 PM, "Alvaro Herrera" <alvherre@alvh.no-ip.org> wrote:
>
>> > I noticed that XLogCtl->lastNotifiedSeg is protected by both the
>> > info_lck and ArchNotifyLock.  I think it it's going to be protected by
>> > the lwlock, then we should drop the use of the spinlock.
>>
>> That seems reasonable to me.  This means that the lock is acquired at
>> the end of every XLogWrite(),
>
> Uhh, actually that there sounds really bad; it's going to be a serious
> contention point.
>
> Another option might be to make it an atomic.

This is why I was trying to get away with just using info_lck for
reading lastNotifiedSeg.  ArchNotifyLock is mostly intended to protect
RecordBoundaryMap.  However, since lastNotifiedSeg is used in
functions like GetLatestRecordBoundarySegment() that access the map, I
found it easier to reason about things if I knew that it wouldn't
change as long as I held ArchNotifyLock.

I think the main downside of making lastNotifiedSeg an atomic is that
the value we first read in NotifySegmentsReadyForArchive() might not
be up-to-date, which means we might hold off creating .ready files
longer than necessary.

Nathan


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

Предыдущее
От: vignesh C
Дата:
Сообщение: Re: [HACKERS] logical decoding of two-phase transactions
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Split xlog.c