On 07/11/14 22:02, Greg Sabino Mullane wrote:
-----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? :)
So do we agree to fix the docs? ^_^
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.
I also think so. It's backwards-compatible and opt-in. It also
makes the documentation very clear, as there is an specific option for this.
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.
+1
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.
If the "IMMEDIATE FREEZE" mode is not the default, as I suggested,
it shouldn't introduce any problem with past code.
Regards,
Álvaro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
