Regarding vacuum freeze locking mechanism

Started by Durgamahesh Manneover 1 year ago5 messagesgeneral
Jump to latest
#1Durgamahesh Manne
maheshpostgres9@gmail.com

Hi

Do new inserts block while performing vacuum freeze operations ?

when autovacuum runs , it will freeze the transaction ID (TXID) of the
table it's working on. This means that any transactions that started before
autovacuum began will be allowed to complete.but new transactions will be
blocked until the autovacuum finishes.

Could you please provide more clarity on this? Which lock triggers on the
tables are being used by freeze?

Your response is highly appreciated

Regards,
Durga Mahesh

#2Kashif Zeeshan
kashi.zeeshan@gmail.com
In reply to: Durgamahesh Manne (#1)
Re: Regarding vacuum freeze locking mechanism

Hi

On Thu, Jul 18, 2024 at 10:26 AM Durgamahesh Manne <
maheshpostgres9@gmail.com> wrote:

Hi

Do new inserts block while performing vacuum freeze operations ?

Generally, VACUUM FREEZE does not block inserts as PG uses Multi-Version
Concurrency Control (MVCC) which allows multiple transactions to operate on
the same table without interfering with each other.

Show quoted text

when autovacuum runs , it will freeze the transaction ID (TXID) of the
table it's working on. This means that any transactions that started before
autovacuum began will be allowed to complete.but new transactions will be
blocked until the autovacuum finishes.

Could you please provide more clarity on this? Which lock triggers on the
tables are being used by freeze?

Your response is highly appreciated

Regards,
Durga Mahesh

#3David G. Johnston
david.g.johnston@gmail.com
In reply to: Durgamahesh Manne (#1)
Re: Regarding vacuum freeze locking mechanism

On Wednesday, July 17, 2024, Durgamahesh Manne <maheshpostgres9@gmail.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.

#4David G. Johnston
david.g.johnston@gmail.com
In reply to: Durgamahesh Manne (#1)
Re: Regarding vacuum freeze locking mechanism

On Wednesday, July 17, 2024, Durgamahesh Manne <maheshpostgres9@gmail.com>
wrote:

Could you please provide more clarity on this? Which lock triggers on the
tables are being used by freeze?

https://www.postgresql.org/docs/current/explicit-locking.html

Share update exclusive

David J.

#5Durgamahesh Manne
maheshpostgres9@gmail.com
In reply to: David G. Johnston (#4)
Re: Regarding vacuum freeze locking mechanism

Hi David.

Excellent response from you .Great

Regards,
Durga Mahesh

On Thu, Jul 18, 2024 at 11:28 AM David G. Johnston <
david.g.johnston@gmail.com> wrote:

Show quoted text

On Wednesday, July 17, 2024, Durgamahesh Manne <maheshpostgres9@gmail.com>
wrote:

Could you please provide more clarity on this? Which lock triggers on the
tables are being used by freeze?

https://www.postgresql.org/docs/current/explicit-locking.html

Share update exclusive

David J.