Re: [DOCS] max_worker_processes on the standby - Mailing list pgsql-hackers

On Wed, Oct 28, 2015 at 3:07 AM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> Alvaro Herrera wrote:
>> Robert Haas wrote:
>> > On Sat, Oct 17, 2015 at 5:37 PM, Petr Jelinek <petr@2ndquadrant.com> wrote:
>> > > I agree with that sentiment.
>> > >
>> > > Attached patch adds variable to the shmem which is used for module
>> > > activation tracking - set to true in ActiveCommitTs() and false in
>> > > DeactivateCommitTs(). All the checks inside the commit_ts code were changed
>> > > to use this new variable. I also removed the static variable Alvaro added in
>> > > previous commit because it's not needed anymore.
>> >
>> > That sounds good to me.  On a quick read-through it looks OK too.
>>
>> A revised version is attached.
>
> Pushed.

I found another strange behavior on track_commit_timestamp.
Here are the steps to reproduce it.

1. Start the master and standby servers with track_commit_timestamp enabled.
    Since committs is activated in standby, pg_last_committed_xact() can
    successfully return the timestamp of last transaction as expected.

2. Disable track_commit_timestamp in the master and restart the master server.
    The parameter-change WAL record is streamed to the standby and committs
    is deactivated. pg_last_committed_xact() causes an ERROR in the standby.

3. Run checkpoint in the master.

4. Run restartpoint in the standby after the checkpoint WAL record generated
    in #3 is replicated to the standby.

5. Restart the standby server.
    Committs is activated in the standby because track_commit_timestamp is
    enabled. Since there is no parameter-change WAL record since last
    restartpoint, committs is not deactivated. So pg_last_committed_xact()
    can successfully return the timestamp.

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.
    Back to the same situation as #2. That is, pg_last_committed_xact() causes
    an ERROR.

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.

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.

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.

Regards,

--
Fujii Masao