MIME-Version: 1.0
In-Reply-To: <20151001181240.GT2573@alvherre.pgsql>
References: 
 <ca44c6c7f9314868bdc521aea4f77cbf@MP-MSGSS-MBX004.msg.nttdata.co.jp>
 <CAHGQGwHereDzzzmfxEBYcVQu3oZv6vZcgu1TPeERWbDc+gQ06g@mail.gmail.com>
 <20150930224806.GR2573@alvherre.pgsql>
 <CAHGQGwHRXGqSYoUf+aTf0icMq8Or6oBcEN+Y=2cZ4wLW_5acHw@mail.gmail.com>
 <20151001181240.GT2573@alvherre.pgsql>
Date: Fri, 2 Oct 2015 12:06:03 +0900
Message-ID: 
 <CAHGQGwGmpuWUHUcMXFrexgYjAvzn7a8mNdZfXzFG8aBjoXyd4w@mail.gmail.com>
Subject: Re: [DOCS] max_worker_processes on the standby
From: Fujii Masao <masao.fujii@gmail.com>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: oonishitk@nttdata.co.jp, pgsql-docs <pgsql-docs@postgresql.org>,
 PostgreSQL-development <pgsql-hackers@postgresql.org>
Content-Type: text/plain; charset=UTF-8
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On Fri, Oct 2, 2015 at 3:12 AM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> Fujii Masao wrote:
>
>> I've not read the patch yet, but the patched server with track_commit_timestamp
>> enabled caused the following PANIC error when I ran pgbench.
>
> Ah, that was a stupid typo: I used || instead of &&.  Fixed that.
>
> I also changed DeactivateCommitTs() so that it removes all slru segments
> instead of leaving the last one around (which is what SimpleLruTruncate
> was doing).  This was noticeable when you ran a server with the feature
> enabled (which created some files), then disabled it (which removed all
> but the last) and ran for some more xacts; then enabled it again (which
> created a new file, far ahead from the previously existing one).  Since
> the feature has enough protections that it doesn't have a problem with
> no files at all being present, this works correctly.  Note no
> wal-logging of this operation: it's not necessary AFAICS because the
> same deactivation routine would be called again in recovery and in
> XLOG_PARAMETER_CHANGE, so it should be safe.

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.

TRAP: FailedAssertion("!(((oldestCommitTs) != ((TransactionId) 0)) ==
((newestCommitTs) != ((TransactionId) 0)))", File: "commit_ts.c",
Line: 307)

LOG:  server process (PID 11160) was terminated by signal 6: Aborted
DETAIL:  Failed process was running: select num,
pg_xact_commit_timestamp(num::text::xid) from generate_series(1750,
1800) num

The steps to reproduce the problem is

1. Set up replication with track_commit_timestamp enabled.
2. Run several write transactions.
3. Disable track_commit_timestamp only in master and wait for
    XLOG_PARAMETER_CHANGE record to be replayed in standby.
4. Run pg_xact_commit_timestamp() in standby.

Regards,

-- 
Fujii Masao


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers