Re: Repeatable read and serializable transactions see data committed after tx start

From: Álvaro Hernández Tortosa <aht(at)nosys(dot)es>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Repeatable read and serializable transactions see data committed after tx start
Date: 2014-11-08 20:53:18
Message-ID: 545E82BE.7090509@nosys.es
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ross Reedstrom 2014-11-08 21:19:36 Re: row_to_json bug with index only scans: empty keys!
Previous Message Álvaro Hernández Tortosa 2014-11-08 20:48:28 Re: Repeatable read and serializable transactions see data committed after tx start