Database Horizon
Hi,
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.
Thanks,
Goti
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