Re: incoherent view of serializable transactions - Mailing list pgsql-hackers

From Tom Lane
Subject Re: incoherent view of serializable transactions
Date
Msg-id 15331.1230007457@sss.pgh.pa.us
Whole thread Raw
In response to incoherent view of serializable transactions  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Responses Re: incoherent view of serializable transactions  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
List pgsql-hackers
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> At this point, SERIALIZABLE transactions appear to have worked, with
> receipt 3 happening before the update of deposit_date; however, there
> was a window of time when the update to deposit_date was visible and
> receipt 3 was not.
> This absolutely can't happen in a standard-compliant implementation.

I think you mean "you'd like to believe that can't happen in a
standard-compliant implementation".  It doesn't include any of the
specific behaviors that are forbidden by the spec, though, so I'm less
than convinced.

An appropriate way to prevent the problem is probably for the
transaction that changes the deposit_date to take out a write-excluding
lock on the receipts table before it does so.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: Lock conflict behavior?
Next
From: Tom Lane
Date:
Subject: Re: encoding cleanups in cvs repo