On Wed, Aug 17, 2011 at 9:53 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
> On Wed, Aug 17, 2011 at 9:40 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Wed, Aug 17, 2011 at 6:19 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
>>> The straightforward approach to address the problem you raised is to log
>>> the change of full_page_writes on the master. Since such a WAL record is also
>>> replicated to the standby, the standby can know whether full_page_writes is
>>> enabled or not in the master, from the WAL record. If it's disabled,
>>> pg_start_backup() in the standby should emit an error and refuse standby-only
>>> backup. If the WAL record indicating that full_page_writes was disabled
>>> on the master arrives during standby-only backup, the standby should cancel
>>> the backup.
>>
>> Seems like something we could add to XLOG_PARAMETER_CHANGE fairly easily.
>
> I'm afraid it's not so easy. Because since fpw can be changed by
> SIGHUP, it's not
> easy to ensure that logging the change of fpw must happen ahead of the actual
> behavior change by that. Probably we need to make the backend which detects
> the change of fpw first log that.
Ugh, you're right. But then you might have problems if the state
changes again before all backends have picked up the previous change.
What I've thought about before is making one backend (say, bgwriter)
store its latest value in shared memory, protected by some lock that
would already be held at the time the value is needed. Everyone else
uses the shared memory copy instead of relying on their local value.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company