On Wed, Nov 23, 2016 at 8:37 AM, Craig Ringer <cr...@2ndquadrant.com> wrote: >>> The last checkpoint's oldestXid, and ShmemVariableCache's oldestXid, >>> are already held down by ProcArray's catalog_xmin. But that doesn't >>> mean we haven't removed newer tuples from specific relations and >>> logged that in xl_heap_clean, etc, including catalogs or user >>> catalogs, it only means the clog still exists for those XIDs. >> >> Really? > > (Note the double negative above). > > Yes, necessarily so. You can't look up xids older than the clog > truncation threshold at oldestXid, per our discussion on txid_status() > and traceable commit. But the tuples from that xact aren't guaranteed > to exist in any given relation; vacuum uses vacuum_set_xid_limits(...) > which calls GetOldestXmin(...); that in turn scans ProcArray to find > the oldest xid any running xact cares about. It might bump it down > further if there's a replication slot requirement or based on > vacuum_defer_cleanup_age, but it doesn't care in the slightest about > oldestXmin. > > oldestXmin cannot advance until vacuum has removed all tuples for that > xid and advanced the database's datfrozenxid. But a given oldestXmin > says nothing about which tuples, catalog or otherwise, still exist and > are acessible.
Right. Sorry, my mistake. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
