Re: Logical decoding on standby

<p dir="ltr"><p dir="ltr">On 26 Nov. 2016 23:40, "Robert Haas" <<a
href="mailto:robertmhaas@gmail.com">robertmhaas@gmail.com</a>>wrote:<br /> ><br /> > On Wed, Nov 23, 2016 at
8:37AM, Craig Ringer <<a href="mailto:craig@2ndquadrant.com">craig@2ndquadrant.com</a>> wrote:<br /> >
>>>The last checkpoint's oldestXid, and ShmemVariableCache's oldestXid,<br /> > >>> are already
helddown by ProcArray's catalog_xmin. But that doesn't<br /> > >>> mean we haven't removed newer tuples
fromspecific relations and<br /> > >>> logged that in xl_heap_clean, etc, including catalogs or user<br />
>>>> catalogs, it only means the clog still exists for those XIDs.<br /> > >><br /> > >>
Really?<br/> > ><br /> > > (Note the double negative above).<br /> > ><br /> > > Yes,
necessarilyso. You can't look up xids older than the clog<br /> > > truncation threshold at oldestXid, per our
discussionon txid_status()<br /> > > and traceable commit. But the tuples from that xact aren't guaranteed<br />
>> to exist in any given relation; vacuum uses vacuum_set_xid_limits(...)<br /> > > which calls
GetOldestXmin(...);that in turn scans ProcArray to find<br /> > > the oldest xid any running xact cares about. It
mightbump it down<br /> > > further if there's a replication slot requirement or based on<br /> > >
vacuum_defer_cleanup_age,but it doesn't care in the slightest about<br /> > > oldestXmin.<br /> > ><br />
>> oldestXmin cannot advance until vacuum has removed all tuples for that<br /> > > xid and advanced the
database'sdatfrozenxid. But a given oldestXmin<br /> > > says nothing about which tuples, catalog or otherwise,
stillexist and<br /> > > are acessible.<br /> ><br /> > Right.  Sorry, my mistake.<p dir="ltr">Phew. Had me
worriedthere.<p dir="ltr">Thanks for looking over it. Prototype looks promising so far.