Re: Logical decoding on standby

On 26 Nov. 2016 23:40, "Robert Haas" <robertmhaas(at)gmail(dot)com> wrote:
>
> On Wed, Nov 23, 2016 at 8:37 AM, Craig Ringer <craig(at)2ndquadrant(dot)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.