Re: [DOCS] max_worker_processes on the standby

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: 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-10-02 03:06:03
Message-ID: CAHGQGwGmpuWUHUcMXFrexgYjAvzn7a8mNdZfXzFG8aBjoXyd4w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-docs pgsql-hackers

On Fri, Oct 2, 2015 at 3:12 AM, Alvaro Herrera <alvherre(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-docs by date

  From Date Subject
Next Message Michael Paquier 2015-10-02 04:11:03 Re: storage.sgml mentioning htup.h when referring to HeapTupleHeaderData
Previous Message Alvaro Herrera 2015-10-01 18:12:40 Re: max_worker_processes on the standby

Browse pgsql-hackers by date

  From Date Subject
Next Message Kouhei Kaigai 2015-10-02 03:10:01 Re: Foreign join pushdown vs EvalPlanQual
Previous Message Michael Paquier 2015-10-02 03:01:39 Re: Obsolete use of volatile in walsender.c, walreceiver.c, walreceiverfuncs.c?