Re: archive status ".ready" files may be created too early
От | Fujii Masao |
---|---|
Тема | Re: archive status ".ready" files may be created too early |
Дата | |
Msg-id | d2b5127c-9df8-48ad-69eb-f4a4feaf9c34@oss.nttdata.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
|
Список | pgsql-hackers |
On 2021/08/24 4:55, alvherre@alvh.no-ip.org wrote: > On 2021-Aug-23, Bossart, Nathan wrote: > >> Ah, okay. BTW the other changes you mentioned made sense to me. > > Thanks. I've pushed this now to all live branches. Thanks a lot! + /* + * There's a chance that the record was already flushed to disk and we + * missed marking segments as ready for archive. If this happens, we + * nudge the WALWriter, which will take care of notifying segments as + * needed. + */ + if (StartSeg != EndSeg && XLogArchivingActive() && + LogwrtResult.Flush >= EndPos && ProcGlobal->walwriterLatch) + SetLatch(ProcGlobal->walwriterLatch); Is this really necessary? 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 this understanding is right, there seems no need to wake walwriter up here so that it can call NotifySegmentsReadyForArchive(LogwrtResult.Flush) gain. Thought? Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
В списке pgsql-hackers по дате отправления: