Re: archive status ".ready" files may be created too early
От | Bossart, Nathan |
---|---|
Тема | Re: archive status ".ready" files may be created too early |
Дата | |
Msg-id | 011A619B-E365-41D7-9FE0-E19BAF0B547F@amazon.com обсуждение исходный текст |
Ответ на | Re: archive status ".ready" files may be created too early (Fujii Masao <masao.fujii@oss.nttdata.com>) |
Список | pgsql-hackers |
On 8/25/21, 11:01 AM, "Fujii Masao" <masao.fujii@oss.nttdata.com> wrote: > If LogwrtResult.Flush >= EndPos, which means that another process already > has flushed the record concurrently and updated XLogCtl->LogwrtResult.Flush. > This situation also means that that another process called > NotifySegmentsReadyForArchive(LogwrtResult.Flush). Right? If the segment boundary wasn't registered before the other process called NotifySegmentsReadyForArchive(), then it couldn't have used the boundary for deciding which .ready files to create. > If this understanding is right, there seems no need to wake walwriter up here > so that it can call NotifySegmentsReadyForArchive(LogwrtResult.Flush) gain. > Thought? We're actually discussing this right now in another thread [0]. I think we might be able to get rid of that part if we move the boundary registration to before we release the WAL insert lock(s). Nathan [0] https://postgr.es/m/DE60B9AA-9670-47DA-9678-6C79BCD884E3%40amazon.com
В списке pgsql-hackers по дате отправления: