Re: old_snapshot_threshold allows heap:toast disagreement

On Wed, Jul 27, 2016 at 7:26 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> Why did you decide to introduce MaximumXLogRecPtr? Wouldn't just using
> InvalidXLogRecPtr do the trick? That already prevents errors.

Oh, right.

>> Also, I wonder why it's right to use
>> pairingheap_first() instead of looking at the oldest snapshot on the
>> active snapshot stack, or conversely why that is right and this is
>> not. Or maybe we need to check both.
>
> Well, generally, the older the snapshot we use is, the more we'll error
> out spuriously. The reason to use the oldest from the pairing heap is
> that that'll be the most conservative value, right? If there's neither
> an active, nor a registered snapshot, we'll not prevent pruning in the
> first place (and xmin ought to be invalid). As registered snapshots are
> usually "older" than active ones, we definitely have to check those. But
> you're right, it seems safer to also check active ones - which squares
> with SnapshotResetXmin().

OK. That's a bit inconvenient because we don't have an O(1) way to
access the bottom of the active snapshot stack; I've attempted to add
such a mechanism here.

>> But there's a bit of spooky action at a
>> distance: if we don't see any snapshots, then we have to assume that
>> the scan is being performed with a non-MVCC snapshot and therefore we
>> don't need to worry. But there's no way to verify that via an
>> assertion, because the connection between the relevant MVCC snapshot
>> and the corresponding TOAST snapshot is pretty indirect, mediated only
>> by snapmgr.c.
>
> Hm. Could we perhaps assert that the session has a valid xmin?

I don't think so. CLUSTER?

New version attached.

(Official status update: I expect to have this issue wrapped up in the
next few days, assuming that review and discussion continue. If for
some reason that fails to be the case, I will provide a further
official status update no later than Tuesday of next week: August 2,
2016.)

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company