Re: Strangeness in xid allocation / snapshot setup - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Strangeness in xid allocation / snapshot setup
Date
Msg-id 10759.994905145@sss.pgh.pa.us
Whole thread Raw
In response to RE: Strangeness in xid allocation / snapshot setup  ("Mikheev, Vadim" <vmikheev@SECTORBASE.COM>)
List pgsql-hackers
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM> writes:
>> Since we are going to treat all xids >= xmax as in-progress anyway,
>> what's wrong with reading xmax before we acquire the SInval lock?

> AFAIR, I made so to prevent following:

> 1. Tx Old is running.
> 2. Tx S reads new transaction ID in GetSnapshotData() and swapped away
>    before SInval acquired.
> 3. Tx New gets new transaction ID, makes changes and commits.
> 4. Tx Old changes some row R changed by Tx New and commits.
> 5. Tx S gets snapshot data and now sees R changed by *both* Tx Old and
>    Tx New *but* does not see *other* changes made by Tx New =>
>    Tx S reads unconsistent data.

Hmm, but that doesn't seem to have anything to do with the way that
GetSnapshotData operates.  If Tx New has an XID >= xmax read by Tx S'
GetSnapshotData, then Tx New will be considered uncommitted by S no
matter which order we get the locks in; it hardly matters whether Tx New
manages to physically commit before we finish building the snapshot for
S.  On the other side of the coin, if Tx New's XID < xmax for S, then
*with the GetNewTransactionId change that I want* we can be sure that
Tx New will be seen running by S when it does get the SInval lock
(unless New has managed to finish before S gets the lock, in which case
it's perfectly reasonable for S to treat it as committed or aborted).

Anyway, it seems to me that the possibility of inconsistent data is
inherent in the way we handle updated rows in Read Committed mode ---
you can always get to see a row that was emitted by a transaction you
don't see the other effects of.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Re: docs Japanese translation
Next
From: Tom Lane
Date:
Subject: Re: Possible bug in plpgsql/src/gram.y