Re: Repeatable read and serializable transactions see data committed after tx start - Mailing list pgsql-hackers

From Greg Sabino Mullane
Subject Re: Repeatable read and serializable transactions see data committed after tx start
Date
Msg-id 5ed8856570a5b3be3e48760e6a2fd8bb@biglumber.com
Whole thread Raw
In response to Re: Repeatable read and serializable transactions see data committed after tx start  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Repeatable read and serializable transactions see data committed after tx start  (Álvaro Hernández Tortosa <aht@nosys.es>)
List pgsql-hackers
-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160


Kevin Grittner wrote:
>> I think most people have always assumed that
>> BEGIN starts the transaction and that is the point at 
>> which the snapshot is obtained.

> But there is so much evidence to the contrary.  Not only does the
> *name* of the command (BEGIN or START) imply a start, but
> pg_stat_activity shows the connection "idle in transaction" after
> the command (and before a snapshot is acquired)

Er...I think we are arguing the same thing here. So no contrary 
needed? :)

> Why?  This "fix" might not deal with the bigger issues that I
> discussed, like that the later-to-start and
> later-to-acquire-a-snapshot transaction might logically be first in
> the apparent order of execution.  You can't "fix" that without a
> lot of blocking -- that most of us don't want.

Right, which is why the suggestion of a user-controllable switch, 
that defaults to the current behavior, seems an excellent compromise.

> Depending on *why* they think this is important, they might need to 
> be acquiring various locks to prevent behavior they don't want, in which case
> having acquired a snapshot at BEGIN would be exactly the *wrong*
> thing to do.  The exact nature of the problem we're trying to solve
> here does matter.

I cannot speak to the OP, but I also do not think we should try and 
figure out every possible scenario people may have. Certainly the 
long-standing documentation bug may have caused some unexpected or 
unwanted behavior, so let's start by fixing that.

Tom Lane wrote:
> Another thing that I think hasn't been mentioned in this thread is
> that we used to have severe problems with client libraries that like
> to issue BEGIN and then go idle until they have something to do.
> Which, for some reason, is a prevalent behavior.

I'm not advocating changing the default behavior, but I would not want 
to see bad client libraries used a reason for any change we make. Clients 
should not be doing this, period, and there is no reason for us to 
support that.

- -- 
Greg Sabino Mullane greg@turnstep.com
End Point Corporation http://www.endpoint.com/
PGP Key: 0x14964AC8 201411071600
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAlRdMwwACgkQvJuQZxSWSsh/mgCeMdrj15bNVtzBhecG+QT2SlKh
jboAnAjctUcrlA2aCCQmIsSM87ulmFEn
=U5ld
-----END PGP SIGNATURE-----





pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: recovery_target_time and standby_mode
Next
From: Peter Geoghegan
Date:
Subject: Re: B-Tree index builds, CLUSTER, and sortsupport