Re: tracking commit timestamps - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: tracking commit timestamps
Date
Msg-id CAHGQGwFhJ3CnHo1CELEfay18yg_RA-XZT-7D8NuWUoYSZ90r4Q@mail.gmail.com
Whole thread Raw
In response to Re: tracking commit timestamps  (Fujii Masao <masao.fujii@gmail.com>)
Responses Re: tracking commit timestamps
List pgsql-hackers
On Thu, Dec 4, 2014 at 12:08 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
> On Wed, Dec 3, 2014 at 11:54 PM, Alvaro Herrera
> <alvherre@2ndquadrant.com> wrote:
>> Pushed with some extra cosmetic tweaks.
>
> I got the following assertion failure when I executed pg_xact_commit_timestamp()
> in the standby server.
>
> =# select pg_xact_commit_timestamp('1000'::xid);
> TRAP: FailedAssertion("!(((oldestCommitTs) != ((TransactionId) 0)) ==
> ((newestCommitTs) != ((TransactionId) 0)))", File: "commit_ts.c",
> Line: 315)
> server closed the connection unexpectedly
>     This probably means the server terminated abnormally
>     before or while processing the request.
> The connection to the server was lost. Attempting reset: 2014-12-04
> 12:01:08 JST sby1 LOG:  server process (PID 15545) was terminated by
> signal 6: Aborted
> 2014-12-04 12:01:08 JST sby1 DETAIL:  Failed process was running:
> select pg_xact_commit_timestamp('1000'::xid);
>
> The way to reproduce this problem is
>
> #1. set up and start the master and standby servers with
> track_commit_timestamp disabled
> #2. enable track_commit_timestamp in the master and restart the master
> #3. run some write transactions
> #4. enable track_commit_timestamp in the standby and restart the standby
> #5. execute "select pg_xact_commit_timestamp('1000'::xid)" in the standby
>
> BTW, at the step #4, I got the following log messages. This might be a hint for
> this problem.
>
> LOG:  file "pg_commit_ts/0000" doesn't exist, reading as zeroes
> CONTEXT:  xlog redo Transaction/COMMIT: 2014-12-04 12:00:16.428702+09;
> inval msgs: catcache 59 catcache 58 catcache 59 catcache 58 catcache
> 45 catcache 44 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7
> catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7
> catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 snapshot 2608
> relcache 16384

This problem still happens in the master.

Regards,

-- 
Fujii Masao



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Typo in function header for recently added function errhidecontext
Next
From: Fujii Masao
Date:
Subject: Re: pg_basebackup -x/X doesn't play well with archive_mode & wal_keep_segments