From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
Cc: | h(at)husseinnasser(dot)com, pgsql-docs(at)lists(dot)postgresql(dot)org |
Subject: | Re: Transaction wraparound and read committed isolation level |
Date: | 2023-02-21 17:46:29 |
Message-ID: | CAH2-Wz=kBfdPbE=ZqFEK0sTO-Abn=j80CpGBV7NB2WHNpT4aPw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs |
On Tue, Feb 21, 2023 at 1:51 AM Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> wrote:
> > If the current transaction isolation level is read committed it absolutely
> > can see rows committed by future transactions with higher XIDs.
>
> You are right, in combination with PlanQualEval you can.
You don't need to bring EvalPlanQual (RC update conflict handling) into it.
All that you need is two statements within the same READ COMMITTED
transaction, combined with a second concurrently executing
transaction. The second transaction need only start after the first
one (giving it a later XID), and then commit before the first
transaction's second statement begins. Each RC statement gets its own
snapshot, so the second statement in the first transaction can see any
effects from the first transaction.
> > this also bear the question that the wraparound isn’t really a problem with
> > default isolation level but more for higher levels such as repeatable read
> > and such.
> >
> > please correct me if my understanding is incorrect.
>
> Wraparound can be a problem on all isolation levels. It has to do with
> transaction IDs and visibility.
The way that the docs explain wraparound is seriously misleading.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2023-02-21 17:49:31 | Re: Transaction wraparound and read committed isolation level |
Previous Message | David G. Johnston | 2023-02-21 15:56:50 | Re: MERGE examples not clear |