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(); CREATE TABLE alvherre=# select ts.* from pg_class,pg_xact_commit_timestamp(xmin) ts where relname = 'fg'; ts ------------------------------- 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: http://www.postgresql.org/mailpref/pgsql-hackers