public inbox for [email protected]  

help / color / mirror / Atom feed

From: Fujii Masao <[email protected]>
To: Alvaro Herrera <[email protected]>
Cc: [email protected]
Cc: pgsql-docs <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Subject: Re: max_worker_processes on the standby
Date: Thu, 8 Oct 2015 02:32:43 +0900
Message-ID: <CAHGQGwEb3HSEBEu3mWYKjxBySr9zfNd4-AcmpqXJhEoDBk9w1w@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <ca44c6c7f9314868bdc521aea4f77cbf@MP-MSGSS-MBX004.msg.nttdata.co.jp>
	<CAHGQGwHereDzzzmfxEBYcVQu3oZv6vZcgu1TPeERWbDc+gQ06g@mail.gmail.com>
	<[email protected]>
	<CAHGQGwHRXGqSYoUf+aTf0icMq8Or6oBcEN+Y=2cZ4wLW_5acHw@mail.gmail.com>
	<[email protected]>
	<CAHGQGwGmpuWUHUcMXFrexgYjAvzn7a8mNdZfXzFG8aBjoXyd4w@mail.gmail.com>
	<[email protected]>
List-Unsubscribe: <mailto:[email protected]?body=unsub%20pgsql-docs>

On Fri, Oct 2, 2015 at 11:58 PM, Alvaro Herrera
<[email protected]> wrote:
> Fujii Masao wrote:
>
>> What happens if pg_xact_commit_timestamp() is called in standby after
>> track_commit_timestamp is disabled in master, DeactivateCommitTs() is
>> called and all commit_ts files are removed in standby? I tried that case
>> and got the following assertion failure.
>
> Ah.  So the standby needs to keep the module activated if it's enabled
> locally, even when it receives a message that the master turned it off.
> Here's a patch.

I'm afraid that this behavior might confuse the users.

Please imagine the following scenario.

1. start up the server with track_commit_timestamp disabled
2. run several transactions
3. shut down the server with immediate mode
4. restart the server with track_commit_timestamp enabled
5. run "SELECT pg_last_committed_xact()"
6. run "SELECT pg_xact_commit_timestamp(xid) FROM pg_last_committed_xact()"
7. restart the server
8. run "SELECT pg_last_committed_xact()"

Firstly, in #5, pg_last_committed_xact() returns the XID and
timestamp of the last transaction which was executed in #2
(i.e., while track_commit_timestamp was disabled).
This is confusing. I think that both pg_last_committed_xact()
and pg_xact_commit_timestamp() should return only the transaction
which was executed with track_commit_timestamp enabled.

Secondly, SELECT query in #6 returns NULL. This means that
pg_xact_commit_timestamp() may not handle the transaction
which pg_last_committed_xact() handles. This is also confusing.

Finally, in #8, pg_last_committed_xact() returns NULL while
it returned non-NULL before the restart. This is also confusing.

Regards,

-- 
Fujii Masao


-- 
Sent via pgsql-docs mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

view thread (38+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  Subject: Re: max_worker_processes on the standby
  In-Reply-To: <CAHGQGwEb3HSEBEu3mWYKjxBySr9zfNd4-AcmpqXJhEoDBk9w1w@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox