Sorry, some auto formatting in recent email. Again wtih fixed formatiing:
I see strange beaviour of txid_status with one of my production servers. SELECT txid_status(txid_current()) -> NULL SELECT txid_current() -> 4447342811 It also returns null for recent commited and aborted transactions. SELECT datname, age(datfrozenxid), datfrozenxid FROM pg_database; template 0239961994 4207340131 postgres 289957756 4157344369 template1 289957661 4157344464 project 682347934 3764954191 GDB shows it happens because of TransactionIdPrecedes(xid, ShmemVariableCache->oldestClogXid)) at txid.c:155. xid_epoch = 1 xid = 150227913 now_epoch = 1 now_epoch_last_xid = 150468261 ShmemVariableCache->oldestClogXid = 2207340131 The strangest thing is ShmemVariableCache->oldestClogXid == 2207340131 which is greater than current xid without an epoch (150227913) . Postgres was updated from 9.6 to PostgreSQL 10.4 (Ubuntu 10.4-2.pgdg14.04+1) on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 4.8.4-2ubuntu1~14.04.4) 4.8.4, 64-bit. Also, another small issue: On the same database: SELECT txid_status(BIGINT '4294967295') -> 'commited'. SELECT txid_status(BIGINT '4294967296') -> NULL Both tx ids are from my head and not valid. First 'commited' happends because int32 overflow: TransactionIdPrecedes(59856482, 2207340131) == false Could anyone help me with understanding of txid_status behaviour? Thanks, Michail. вт, 25 сент. 2018 г. в 19:47, Michail Nikolaev <michail.nikol...@gmail.com>: > Hello everyone. > > I see strange beaviour of txid_status with one of my production servers. > > SELECT txid_status(txid_current()) -> NULL > SELECT txid_current() -> 4447342811 > > It also returns null for recent commited and aborted transactions. > > SELECT datname, age(datfrozenxid), datfrozenxid FROM pg_database; > template 0239961994 4207340131 > postgres 289957756 4157344369 <(415)%20734-4369> > template1 289957661 4157344464 <(415)%20734-4464> > project 682347934 3764954191 > > GDB shows it happens because of TransactionIdPrecedes(xid, > ShmemVariableCache->oldestClogXid)) at txid.c:155. > > xid_epoch = 1 > xid = 150227913 > now_epoch = 1 > now_epoch_last_xid = 150468261 > ShmemVariableCache->oldestClogXid = 2207340131 <(220)%20734-0131> > > The strangest thing is ShmemVariableCache->oldestClogXid == 2207340131 > <(220)%20734-0131> which is greater than current xid without an epoch > (150227913) . > > Postgres was updated from 9.6 to PostgreSQL 10.4 (Ubuntu > 10.4-2.pgdg14.04+1) on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu > 4.8.4-2ubuntu1~14.04.4) 4.8.4, 64-bit. > > Also, another small issue: > > On the same database: > SELECT txid_status(BIGINT '4294967295') -> 'commited'. > SELECT txid_status(BIGINT '4294967296') -> NULL > > Both tx ids are from my head and not valid. > First 'commited' happends because int32 overflow: > TransactionIdPrecedes(59856482, 2207340131 <(220)%20734-0131>) == false > > Could anyone help me with understanding of txid_status behaviour? > > Thanks, > Michail. >
