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 по дате отправления: