From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
---|---|
To: | Goti <aryan(dot)goti(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Database Horizon |
Date: | 2022-09-23 02:55:05 |
Message-ID: | 8210f5ee77d334b8ee70881f9293f337aa9f2510.camel@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Thu, 2022-09-22 at 19:30 +0530, Goti wrote:
> I was reading through snapshot chapter in Egor Rogov's postgres internals and there I
> came across the below.. I am not sure how this is possible and how can I reproduce?
> Can someone explain the below 2 points if possible?
>
> A real transaction at the Read Committed isolation level holds the database horizon
> in the same way, even if it is not executing any operators (being in the “idle in trasaction” state).
>
> A virtual transaction at the Read Committed isolation level holds the horizon only while
> executing operators.
A transaction that changed something (this is what is meant by a "real transaction")
has a transaction ID. VACUUM will not clean up tuples that have been invalidated after the
start of such a transaction, if the transaction is still active. The transaction ID sets the
"xmin horizon" in such a case.
For a reading transaction, it is the xmin horizon of the current snapshot that holds back
VACUUM. For a READ COMMITTED transaction, there is only a snapshot for running statements
and open cursors.
Yours,
Laurenz Albe
--
Cybertec | https://www.cybertec-postgresql.com
From | Date | Subject | |
---|---|---|---|
Next Message | Jerry Sievers | 2022-09-23 04:02:44 | Re: pg_dump failed with error code 255, but I don't see why |
Previous Message | Martin Kalcher | 2022-09-22 15:40:17 | Re: [PATCH] Introduce array_shuffle() and array_sample() |