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  ("Bossart, Nathan" <bossartn@amazon.com>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: The Free Space Map: Problems and Opportunities
Следующее
От: "Bossart, Nathan"
Дата:
Сообщение: Re: prevent immature WAL streaming