Re: Do not lock tables in get_tables_to_repack

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/