On 26 Nov. 2016 23:40, "Robert Haas" <robertmh...@gmail.com> wrote: > > 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.
Phew. Had me worried there. Thanks for looking over it. Prototype looks promising so far.
