public inbox for [email protected]  

help / color / mirror / Atom feed

From: Bharath Rupireddy <[email protected]>
To: cca5507 <[email protected]>
Cc: pgsql-hackers <[email protected]>
Cc: Antonin Houska <[email protected]>
Cc: Alvaro Herrera <[email protected]>
Subject: Re: Do not lock tables in get_tables_to_repack
Date: Sat, 27 Jun 2026 12:56:04 -0700
Message-ID: <CALj2ACU8CwKsdnJQ=U5UU-HcU0m+M-EiejfEU_6zycq0717REQ@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>

Hi,

On Tue, Jun 16, 2026 at 12:35 AM cca5507 <[email protected]> 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.g...

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

view thread (11+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Do not lock tables in get_tables_to_repack
  In-Reply-To: <CALj2ACU8CwKsdnJQ=U5UU-HcU0m+M-EiejfEU_6zycq0717REQ@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox