Re: Issues with ON CONFLICT UPDATE and REINDEX CONCURRENTLY
| От | Mihail Nikalayeu |
|---|---|
| Тема | Re: Issues with ON CONFLICT UPDATE and REINDEX CONCURRENTLY |
| Дата | |
| Msg-id | CADzfLwXLcyEfmQx9FrdVQ-r589YTQsbK04gpNk5HP4XgMDb=Tg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Issues with ON CONFLICT UPDATE and REINDEX CONCURRENTLY (Álvaro Herrera <alvherre@kurilemu.de>) |
| Список | pgsql-hackers |
Hello! On Sun, Dec 7, 2025 at 10:07 PM Álvaro Herrera <alvherre@kurilemu.de> wrote: > I'd rather consider the idea of avoiding indexes marked !indisvalid on > partitioned tables as arbiter lists ... but then we need to verify the > scenario where there is one, and INSERT ON CONFLICT runs concurrently > with ALTER INDEX ATTACH PARTITION for the last partition lacking the > index (which is the point where the index is marked indisvalid on the > partitioned table). There may not be a problem with that, because we > grab AccessExclusiveLock on the index partition, so no query can be > running concurrently ... unless the INSERT is targeting a partition > other than the one where the index is being attached. (On the > partitioned table and index, we only have ShareUpdateExclusiveLock). For my taste it feels too complicated for such a case. What is about changing the logic of this check to the next: For each valid index used as arbiter in a partitioned table we need to have a valid in particular partition (but it is okay to also have an "ready"-only as additional). If some of the arbiters is invalid in the partitioned table (but we have valid compatible in any case) - it is okay. We just have to have an appropriate "companion" for every valid arbiter. Such a check looks correct to me, at least at the very end of the weekend. Thanks, Mikhail.
В списке pgsql-hackers по дате отправления: