Feedback-ID: ie3de48e3:Fastmail
Date: Tue, 7 Jul 2026 18:53:39 +0200
From: =?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@kurilemu.de>
To: cca5507 <cca5507@qq.com>
Cc: pgsql-hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Do not lock tables in get_tables_to_repack
Message-ID: <ak0ujOl6WeakTEqx@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="op6mnexl7cn72cto"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <tencent_9F290B256A3F52B66542F1140E32ECC64309@qq.com>
Archived-At: 
 <https://www.postgresql.org/message-id/ak0ujOl6WeakTEqx%40alvherre.pgsql>
Precedence: bulk


--op6mnexl7cn72cto
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

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/

--op6mnexl7cn72cto
Content-Type: text/x-diff; charset=utf-8
Content-Disposition: attachment;
	filename=v2-0001-Do-not-lock-tables-in-get_tables_to_repack.patch