Re: CREATE INDEX CONCURRENTLY on partitioned index

Поиск
Список
Период
Сортировка
От Ilya Gladyshev
Тема Re: CREATE INDEX CONCURRENTLY on partitioned index
Дата
Msg-id 8fe0027c-a4f9-43a0-afc1-20362c159d07@gmail.com
обсуждение исходный текст
Ответ на Re: CREATE INDEX CONCURRENTLY on partitioned index  (Alexander Pyhalov <a.pyhalov@postgrespro.ru>)
Ответы Re: CREATE INDEX CONCURRENTLY on partitioned index
Re: CREATE INDEX CONCURRENTLY on partitioned index
Список pgsql-hackers
Hi,

I think it's well worth the effort to revive the patch, so I rebased it 
on master, updated it and will return it back to the commitfest. 
Alexander, Justin feel free to add yourselves as authors

On 29.01.2024 12:43, Alexander Pyhalov wrote:
> Hi.
>
> I've rebased patch on master and it'seems to me there's one more issue -
>
> when we call DefineIndexConcurrentInternal() in partitioned case, it 
> waits for transactions, locking tableId, not tabrelid - heaprelid 
> LockRelId is constructed for parent index relation, not for child 
> index relation.
>
> Attaching fixed version.
>
> Also I'm not sure what to do with locking of child relations. If we 
> don't do anything, you can drop one of the partitioned table childs 
> while CIC is in progress, and get error
>
> ERROR:  cache lookup failed for index 16399
I agree that we need to do something about it, in particular, I think we 
should lock all the partitions inside the transaction that builds the 
catalog entries. Fixed this in the new version.
> If you try to lock all child tables in CIC session, you'll get deadlocks.

Do you mean the deadlock between the transaction that drops a partition 
and the transaction doing CIC? I think this is unavoidable and can be 
reproduced even without partitioning.

Also not sure why a list of children relation was obtained with 
ShareLock that CIC is supposed to avoid not to block writes, changed 
that to ShareUpdateExclusive.

Regards,

Ilya


Вложения

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

Предыдущее
От: Bertrand Drouvot
Дата:
Сообщение: Re: Avoid orphaned objects dependencies, take 3
Следующее
От: "Karki, Sanjay"
Дата:
Сообщение: PG catalog