Re: Do not lock tables in get_tables_to_repack - Mailing list pgsql-hackers

From cca5507
Subject Re: Do not lock tables in get_tables_to_repack
Date
Msg-id tencent_39EA60C72E2394B930B416286544061F8F05@qq.com
Whole thread
In response to Re: Do not lock tables in get_tables_to_repack  (Álvaro Herrera <alvherre@kurilemu.de>)
Responses Re: Do not lock tables in get_tables_to_repack
List pgsql-hackers
> > 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

pgsql-hackers by date:

Previous
From: Erik Rijkers
Date:
Subject: Re: pgsql: Cleanup comments/docs around the new shmem request callbacks
Next
From: Fujii Masao
Date:
Subject: Re: pg_recvlogical: send final feedback on SIGINT/SIGTERM exit