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
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 |
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? |