Fujii Masao wrote:

> Sorry for not reviewing the patch before you push it...
> In HEAD, I ran very simple test case:
> 1. enable track_commit_timestamp
> 2. start the server
> 3. run some transactions
> 4. execute pg_last_committed_xact() -- returns non-null values
> 5. shutdown the server with immdiate mode
> 6. restart the server -- crash recovery happens
> 7. execute pg_last_committed_xact()
> The last call of pg_last_committed_xact() returns NULL values, which means
> that the xid and timestamp information of the last committed transaction
> disappeared by crash recovery. Isn't this a bug?

Hm, not really, because the status of the "last" transaction is kept in
shared memory as a cache and not expected to live across a restart.
However, I tested the equivalent scenario:

alvherre=# create table fg();

alvherre=# select ts.* from pg_class,pg_xact_commit_timestamp(xmin) ts where 
relname = 'fg';
 2015-12-04 12:41:48.017976-03
(1 fila)

then crash the server, and after recovery the data is gone:

alvherre=# select ts.*, xmin, c.relname from pg_class 
c,pg_xact_commit_timestamp(xmin) ts where relname = 'fg';
 ts | xmin | relname 
    |  630 | fg
(1 fila)

Not sure what is going on; my reading of the code certainly says that
the data should be there.  I'm looking into it.

I also noticed that I didn't actually push the whole of the patch
yesterday -- I neglected to "git add" the latest changes, the ones that
fix the promotion scenario :-( so the commit messages is misleading
because it describes something that's not there.

Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to