public inbox for [email protected]
help / color / mirror / Atom feedFrom: =?utf-8?B?Y2NhNTUwNw==?= <[email protected]>
To: =?utf-8?B?w4FsdmFybyBIZXJyZXJh?= <[email protected]>
Cc: =?utf-8?B?cGdzcWwtaGFja2Vycw==?= <[email protected]>
Subject: Re: Do not lock tables in get_tables_to_repack
Date: Wed, 8 Jul 2026 10:36:38 +0800
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
> > 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?
- classtup = SearchSysCache1(RELOID, ObjectIdGetDatum(index->indrelid));
+ classtup = SearchSysCacheCopy1(RELOID, ObjectIdGetDatum(index->indrelid));
Do we really need to copy it? We hold a refcount on it so it won't be freed
until we release it. Otherwise LGTM.
--
Regards,
ChangAo Chen
view thread (11+ messages)
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]
Subject: Re: Do not lock tables in get_tables_to_repack
In-Reply-To: <[email protected]>
* 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