Re: Repeatable Read Isolation Level "transaction start time"

From: Greg Sabino Mullane <htamfids(at)gmail(dot)com>
To: Christophe Pettus <xof(at)thebuild(dot)com>
Cc: Ron Johnson <ronljohnsonjr(at)gmail(dot)com>, "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Repeatable Read Isolation Level "transaction start time"
Date: 2024-09-25 21:50:06
Message-ID: CAKAnmm+pudxS+6P8QWH-hf9sUcUN8LuY2tQpc+8_-Gnwi2WNRQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, Sep 25, 2024 at 4:54 PM Christophe Pettus <xof(at)thebuild(dot)com> wrote:

> On Sep 25, 2024, at 13:49, Greg Sabino Mullane <htamfids(at)gmail(dot)com> wrote:
> > BEGIN ISOLATION MODE REPEATABLE READ SNAPSHOT NOW;
>
> This might well be a failure of imagination on my part, but when would it
> pragmatically matter that the snapshot is taken at the first statement as
> opposed to at BEGIN?

I could imagine lots of cases where you know something is about to happen
(say, a major delete), and you want to get a snapshot of the database as it
existed just before that point. Many people will (quite understandably)
assume that a BEGIN ISOLATION MODE <non read committed>; command would do
just that, and be quite surprised to find that when they actually query the
table in that first process, the rows are not there.

It's certainly a non-intuitive behavior. I understand why we do it this
way, but perhaps this warrants a stronger warning in the docs at least?
It's too late in the day for me to tackle that now, but I'll throw it out
there.

Cheers,
Greg

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Peter J. Holzer 2024-09-25 21:55:54 Re: Repeatable Read Isolation Level "transaction start time"
Previous Message Greg Sabino Mullane 2024-09-25 21:32:23 Re: PgBackRest : Restore to a checkpoint shows further transactions