Re: Problem while setting the fpw with SIGHUP

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Problem while setting the fpw with SIGHUP
Дата
Msg-id 20180411202414.GA32449@paquier.xyz
обсуждение исходный текст
Ответ на Re: Problem while setting the fpw with SIGHUP  (Heikki Linnakangas <hlinnaka@iki.fi>)
Ответы Re: Problem while setting the fpw with SIGHUP  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Список pgsql-hackers
On Wed, Apr 11, 2018 at 02:09:48PM +0300, Heikki Linnakangas wrote:
> I think the new behavior where the GUC only takes effect at next checkpoint
> is OK. It seems quite intuitive.
>
> > [rebased patch version]
>
> Looks good at a quick glance. Assuming no objections from others, I'll take
> a closer look and commit tomorrow. Thanks!

Sorry for not following up closely this thread lately.

+   /*
+    * If full_page_writes has been turned off, issue XLOG_FPW_CHANGE before
+    * the flag actually takes effect. No lock is required since checkpointer
+    * is the only updator of shared fullPageWrites after recovery is
+    * finished. Both shared and local fullPageWrites do not change before the
+    * next reading below.
+    */
+   if (Insert->fullPageWrites && !fullPageWrites)
+   {
+       XLogBeginInsert();
+       XLogRegisterData((char *) (&fullPageWrites), sizeof(bool));
+       XLogInsert(RM_XLOG_ID, XLOG_FPW_CHANGE);
+   }

This is not actually true.  If a fallback_promote is used, then
CreateCheckPoint() is called by the startup process which is in charge
of issuing the end-of-recovery checkpoint, and not the checkpointer.  So
I still fail to see how a no-lock approach is fine except if we remove
fallback_promote?
--
Michael

Вложения

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

Предыдущее
От: Daniel Gustafsson
Дата:
Сообщение: Re: Gotchas about pg_verify_checksums
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Bugs in TOAST handling, OID assignment and redo recovery