On Fri, Jul 21, 2017 at 4:16 PM, Neha Sharma <neha.sha...@enterprisedb.com> wrote: > > Attached is the core dump file received on PG 10beta2 version.
Thanks Neha. It's be best to post the back trace and if possible print oldestXact and ShmemVariableCache->oldestXid from the stack frame for TruncateCLOG. The failing assertion in TruncateCLOG() has a comment that says "vac_truncate_clog already advanced oldestXid", but vac_truncate_clog calls SetTransactionIdLimit() to write ShmemVariableCache->oldestXid *after* it calls TruncateCLOG(). What am I missing here? What actually prevents ShmemVariableCache->oldestXid from going backwards anyway? Suppose there are two or more autovacuum processes that reach vac_truncate_clog() concurrently. They do a scan of pg_database whose tuples they access without locking through a pointer-to-volatile because they expect concurrent in-place writers, come up with a value for frozenXID, and then arrive at SetTransactionIdLimit() in whatever order and clobber ShmemVariableCache->oldestXid. What am I missing here? -- Thomas Munro http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers