| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | Durgamahesh Manne <maheshpostgres9(at)gmail(dot)com> |
| Cc: | "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>, "andrian(dot)klaver(at)aklaver(dot)com" <andrian(dot)klaver(at)aklaver(dot)com> |
| Subject: | Re: Regarding vacuum freeze locking mechanism |
| Date: | 2024-07-18 05:53:21 |
| Message-ID: | CAKFQuwYZO8d0x=cnseo0RRZS7JAbC-=c2hkZ_mxetBheb6NELQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Wednesday, July 17, 2024, Durgamahesh Manne <maheshpostgres9(at)gmail(dot)com>
wrote:
> when autovacuum runs , it will freeze the transaction ID (TXID) of the
> table it's working on.
>
This statement is incorrect. A table as a whole does not have a txid.
Freezing makes it so individual tuples get assigned an always-in-the-past
txid. Then, the table can recompute how far away its furthest back txid is
from being considered in-the-future. That gap should increase since the
furthest away txids were the ones being frozen.
Inserts might get delayed a brief moment if it just happens the page they
want to insert onto is presently being worked on. But the odds there seem
low.
David J.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David G. Johnston | 2024-07-18 05:58:40 | Re: Regarding vacuum freeze locking mechanism |
| Previous Message | Kashif Zeeshan | 2024-07-18 05:28:03 | Re: Regarding vacuum freeze locking mechanism |