On Sat, Dec 5, 2015 at 12:56 AM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > 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.
So firstly you will push those "latest" changes soon? Regards, -- Fujii Masao -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
