Thread: is cachedFetchXid ever invalidated?
I can't see any place that "cachedFetchXid" is ever invalidated. Shouldn't it be invalidated before transaction ID wraparound? It's difficult to construct a test case to show whether this is a problem or not, but I couldn't find how this is solved in the code. My understanding is that, before truncating the clog, we need to make sure that there are no references to any transaction IDs that would be cut off. Regards,Jeff Davis
Jeff Davis <pgsql@j-davis.com> writes:
> I can't see any place that "cachedFetchXid" is ever invalidated.
> Shouldn't it be invalidated before transaction ID wraparound?
The assumption is that the value won't sit there (in a particular
session), without ever being replaced, while more than 2G transactions
elapse. Actually you'd need a full 4G transactions to elapse, and then
to wake up just in time to probe the doppelganger of the very same
transaction number, in order to have any risk of a failure.
If that makes you uncomfortable, I've got bad news: there are quite a
few other assumptions of the same ilk about the lifespan of a single
session. One comparable failure case is that starting a transaction
that acquires an XID, and then going to sleep for ~2G transactions,
will cause all kinds of trouble.
regards, tom lane
On Wed, 2010-12-01 at 23:34 -0500, Tom Lane wrote: > Jeff Davis <pgsql@j-davis.com> writes: > > I can't see any place that "cachedFetchXid" is ever invalidated. > > Shouldn't it be invalidated before transaction ID wraparound? > > The assumption is that the value won't sit there (in a particular > session), without ever being replaced, while more than 2G transactions > elapse. Actually you'd need a full 4G transactions to elapse, and then > to wake up just in time to probe the doppelganger of the very same > transaction number, in order to have any risk of a failure. Yeah, it's pretty far-fetched. > One comparable failure case is that starting a transaction > that acquires an XID, and then going to sleep for ~2G transactions, > will cause all kinds of trouble. I think it's well-known that holding a transaction open indefinitely causes problems. I had assumed that a session was different (for instance, a connection pool might keep connections around for a long time). I'll re-align that assumption with reality. Regards,Jeff Davis
Excerpts from Jeff Davis's message of mié dic 01 22:48:36 -0300 2010: > I can't see any place that "cachedFetchXid" is ever invalidated. > Shouldn't it be invalidated before transaction ID wraparound? > > It's difficult to construct a test case to show whether this is a > problem or not, Couldn't you just create a C function that advanced the Xid counter by, say, 100k? -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support