Re: Do not lock tables in get_tables_to_repack

From: Álvaro Herrera <alvherre(at)kurilemu(dot)de>
To: cca5507 <cca5507(at)qq(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Do not lock tables in get_tables_to_repack
Date: 2026-07-07 16:53:39
Message-ID: ak0ujOl6WeakTEqx@alvherre.pgsql
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2026-Jun-16, cca5507 wrote:

> Hi hackers,
>
> When doing a whole database repack, we build a list of repackable
> tables and take a lock on them to prevent concurrent drops. But
> concurrent drops can always happen after we build the list because
> we process each table in a separate transaction.

Not only that. We have actually three ways to obtain the list of tables
to repack, and only one of these obtains the locks. So this code is
internally inconsistent. I agree that we should do something like your
patch. I wanted to be a little more defensive though; how about the
attached?

--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/

Attachment Content-Type Size
v2-0001-Do-not-lock-tables-in-get_tables_to_repack.patch text/x-diff 5.4 KB
v2-0002-fixups.patch text/x-diff 3.9 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Zsolt Parragi 2026-07-07 17:00:21 Proposal: new file format for hba/ident/hosts configuration?
Previous Message Rui Zhao 2026-07-07 16:53:04 Re: [PATCH] Add pg_get_table_ddl() to reconstruct CREATE TABLE statements