Is cachedFetchXidStatus provably valid?
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?
merlin
Merlin Moncure <mmoncure@gmail.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.
regards, tom lane
On Wed, Jun 13, 2012 at 3:55 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Merlin Moncure <mmoncure@gmail.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