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