Re: PATCH: Add REINDEX tag to event triggers
От | jian he |
---|---|
Тема | Re: PATCH: Add REINDEX tag to event triggers |
Дата | |
Msg-id | CACJufxGjd+Za5wnvRnnFXnPz=mtc2ZU_pRknoQKxvCAisFMMsA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: PATCH: Add REINDEX tag to event triggers (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: PATCH: Add REINDEX tag to event triggers
|
Список | pgsql-hackers |
On Fri, Oct 27, 2023 at 3:15 PM Michael Paquier <michael@paquier.xyz> wrote: > > On Mon, Sep 04, 2023 at 08:00:52PM +0200, Jim Jones wrote: > > LGTM. It applies and builds cleanly, all tests pass and documentation also > > builds ok. The CFbot seems also much happier now :) > > + /* > + * Open and lock the relation. ShareLock is sufficient since we only need > + * to prevent schema and data changes in it. The lock level used here > + * should match catalog's reindex_relation(). > + */ > + rel = try_table_open(relid, ShareLock); > > I was eyeing at 0003, and this strikes me as incorrect. Sure, this > matches what reindex_relation() does, but you've missed that > CONCURRENTLY takes a lighter ShareUpdateExclusiveLock, and ShareLock > conflicts with it. See: > https://www.postgresql.org/docs/devel/explicit-locking.html > > So, doesn't this disrupt a concurrent REINDEX? > -- > Michael ReindexPartitions called ReindexMultipleInternal ReindexRelationConcurrently add reindex_event_trigger_collect to cover it. (line 3869) ReindexIndex has the function reindex_event_trigger_collect. (line 2853) reindex_event_trigger_collect_relation called in ReindexMultipleInternal, ReindexTable (line 2979). Both are "under concurrent is false" branches. So it should be fine.
В списке pgsql-hackers по дате отправления: