Re: tracking commit timestamps

On 05/01/15 16:17, Petr Jelinek wrote:
> On 05/01/15 07:28, Fujii Masao wrote:
>> 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,
>>
>
> Attached patch fixes it, I am not sure how happy I am with the way I did
> it though.
>

Added more comments and made the error message bit clearer.

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