MIME-Version: 1.0
References: <tencent_9F290B256A3F52B66542F1140E32ECC64309@qq.com>
In-Reply-To: <tencent_9F290B256A3F52B66542F1140E32ECC64309@qq.com>
From: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Date: Sat, 27 Jun 2026 12:56:04 -0700
Message-ID: 
 <CALj2ACU8CwKsdnJQ=U5UU-HcU0m+M-EiejfEU_6zycq0717REQ@mail.gmail.com>
Subject: Re: Do not lock tables in get_tables_to_repack
To: cca5507 <cca5507@qq.com>
Cc: pgsql-hackers <pgsql-hackers@lists.postgresql.org>,
 Antonin Houska <ah@cybertec.at>,
	Alvaro Herrera <alvherre@alvh.no-ip.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CALj2ACU8CwKsdnJQ%3DU5UU-HcU0m%2BM-EiejfEU_6zycq0717REQ%40mail.gmail.com>
Precedence: bulk

Hi,

On Tue, Jun 16, 2026 at 12:35=E2=80=AFAM cca5507 <cca5507@qq.com> 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. The
> ConditionalLockRelationOid() also makes the default behavior like
> SKIP_LOCKED, which is unexpected.
>
> To remove the locks, we need to make repack_is_permitted_for_relation()
> handles concurrent drops correctly: it should not report an error
> when failing to search the syscache in pg_class_aclcheck(). Use
> pg_class_aclcheck_ext() instead to detect a concurrent drop. Also
> check the return value of get_rel_name().
>
> Thoughts?

I don't have a strong opinion on fixing this for REPACK. For vacuum,
we wanted to get consistent behavior across all modes of invoking it
[1]. Whether to handle concurrent drops for REPACK depends on how long
it spends scanning pg_index/pg_class in get_tables_to_repack. Also,
vacuum is more commonly run database-wide (against all tables), and
without field experience showing this is a real problem for REPACK,
I'm not sure the fix is needed. That said, others may have a different
take - adding the REPACK authors here for their input.

[1] https://www.postgresql.org/message-id/CALj2ACUbhDFJWSwiyoUxXED2S2fr9Xis=
%3D08Rnjq53UzBE4FvzA%40mail.gmail.com

--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com