Re: Is cachedFetchXidStatus provably valid?

On Wed, Jun 13, 2012 at 3:55 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Merlin Moncure <mmoncure(at)gmail(dot)com> writes:
>> It's probably an academic concern, but what happens if a backend saves
>> off cachedFetchXidStatus and then sleeps for a very long time.  During
>> that time an xid wraparound happens and the backend wakes up and
>> happens to read another unhinted tuple with the same xid and a
>> different commit status.  This is obviously incredibly unlikely, but
>> shouldn't cachedFetchXid be cleared at some appropriate point --
>> perhaps end of transaction?
>
> Well, aside from what the odds might be of hitting the case if you did
> manage to sleep through an XID wraparound, I think it's impossible for a
> backend to sleep that long, because of cache inval signals.  (Or, to
> put it differently, a backend has typically got a whole lot of XIDs
> cached within tuples in its syscaches.  cachedFetchXidStatus is the
> least of its worries if it fails to engage in cache inval activity.)
>
> If we had a multiple-entry cache in place of the single-entry cache,
> I think this would be a more realistic concern.  You'd need some way to
> flush old entries from that cache, rather than being able to expect
> that the single entry would get overwritten with newer values anytime
> something happened.

Right -- thanks for that -- I figured as much.

merlin