Re: ALTER tbl rewrite loses CLUSTER ON index

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: ALTER tbl rewrite loses CLUSTER ON index
Дата
Msg-id 20200403065438.GA78887@paquier.xyz
обсуждение исходный текст
Ответ на Re: ALTER tbl rewrite loses CLUSTER ON index  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: ALTER tbl rewrite loses CLUSTER ON index
Список pgsql-hackers
On Thu, Apr 02, 2020 at 04:38:36AM -0300, Alvaro Herrera wrote:
> I don't think we need to worry about that problem, because we already
> checked that the pg_class tuple for the index is there two lines above.
> The pg_index tuple cannot have gone away on its own; and the index can't
> be deleted either, because cluster_rel holds AEL on the table.  There
> isn't "probably" about the can't-happen condition, is there?

Yes, you are right here.  I was wondering about an interference with
the multi-relation cluster that would not lock the parent relation at
the upper level of cluster() but the check on the existence of the
index makes sure that we'll never see an invalid entry in pg_index, so
let's keep patch 0002 as originally presented.  As the commit tree is
going to be rather crowded until feature freeze on Sunday, I'll wait
until Monday or Tuesday to finalize this patch set.

Now, would it be better to apply the refactoring patch for HEAD before
feature freeze, or are people fine if this is committed a bit after?
Patch 0002 is neither a new feature, nor an actual bug, and just some
code cleanup, but I am a bit worried about applying that cleanup on
HEAD just after the freeze.
--
Michael

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: User Interface for WAL usage data
Следующее
От: "David G. Johnston"
Дата:
Сообщение: Re: Syntax rules for a text value inside the literal for a user-defined type—doc section “8.16.2. Constructing Composite Values”