On Wed, Jun 13, 2012 at 3:55 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Merlin Moncure <mmonc...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
