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 по дате отправления: