Re: [DOCS] max_worker_processes on the standby

From: Petr Jelinek <petr(at)2ndquadrant(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, oonishitk(at)nttdata(dot)co(dot)jp, pgsql-docs <pgsql-docs(at)postgresql(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [DOCS] max_worker_processes on the standby
Date: 2015-12-03 16:19:53
Message-ID: 56606BA9.1050606@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-docs pgsql-hackers

On 2015-11-16 22:43, Alvaro Herrera wrote:
> I paraphrase Fujii Masao, who wrote:
>
>> 1. Start the master and standby servers with track_commit_timestamp enabled.
>> 2. Disable track_commit_timestamp in the master and restart the master server.
>> 3. Run checkpoint in the master.
>> 4. Run restartpoint in the standby after the checkpoint WAL record generated
>> 5. Restart the standby server.
>> 6. Enable track_commit_timestamp in the master and restart the master server.
>> 7. Disable track_commit_timestamp in the master and restart the master server.
>
>> What I think strange is that pg_last_committed_xact() behaves differently
>> in #2, #5, and #7 though the settings of track_commit_timestamp are same
>> in both servers, i.e., it's disabled in the master but enabled in the standby.
>
> Interesting, thanks. You're right that this behaves oddly.
>
> I think in order to fix these two points (#5 and #7), we need to make
> the standby not honour the GUC at all, i.e. only heed what the master
> setting is.
>
>> 8. Promote the standby server to new master.
>> Since committs is still inactive even after the promotion,
>> pg_last_committed_xact() keeps causing an ERROR though
>> track_commit_timestamp is on.
>>
>> I was thinking that whether committs is active or not should depend on
>> the setting of track_commit_timestamp *after* the promotion.
>> The behavior in #8 looked strange.
>
> To fix this problem, we can re-run StartupCommitTs() after recovery is
> done, this time making sure to honour the GUC setting.
>
> I haven't tried the scenarios we fixed with the previous round of
> patching, but this patch seems to close the problems just reported.
> (My next step will be looking over the recovery test framework by
> Michael et al, so that I can apply a few tests for this stuff.)
> In the meantime, if you can look this over I would appreciate it.
>

While this seems good, I'd code it slightly differently. I didn't like
the addition of new bool when it's not really needed. This brings the
question if we actually need the BootStrapCommitTs and StartupCommitTs
functions which really don't do much though.

--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

Attachment Content-Type Size
committs-activation-fix.patch binary/octet-stream 1.8 KB

In response to

Responses

Browse pgsql-docs by date

  From Date Subject
Next Message Alvaro Herrera 2015-12-03 22:30:14 Re: [DOCS] max_worker_processes on the standby
Previous Message Bruce Momjian 2015-12-01 13:23:47 Re: ARRAY[1] || NULL <> array_append(ARRAY[1], NULL)

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2015-12-03 16:27:01 Re: [RFC] overflow checks optimized away
Previous Message Greg Stark 2015-12-03 16:08:16 Re: [RFC] overflow checks optimized away