Re: tracking commit timestamps

On 05/01/15 07:28, Fujii Masao wrote:
> On Thu, Dec 4, 2014 at 12:08 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>> On Wed, Dec 3, 2014 at 11:54 PM, Alvaro Herrera
>> <alvherre(at)2ndquadrant(dot)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,
>

Attached patch fixes it, I am not sure how happy I am with the way I did
it though.

And while at it I noticed that redo code for XLOG_PARAMETER_CHANGE sets
ControlFile->wal_log_hints = wal_log_hints;
shouldn't it be
ControlFile->wal_log_hints = xlrec.wal_log_hints;
instead?

--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services