Re: Issues with ON CONFLICT UPDATE and REINDEX CONCURRENTLY
| От | Álvaro Herrera |
|---|---|
| Тема | Re: Issues with ON CONFLICT UPDATE and REINDEX CONCURRENTLY |
| Дата | |
| Msg-id | 202601261855.btsbm3vgwpos@alvherre.pgsql обсуждение исходный текст |
| Ответ на | Re: Issues with ON CONFLICT UPDATE and REINDEX CONCURRENTLY (Mihail Nikalayeu <mihailnikalayeu@gmail.com>) |
| Ответы |
Re: Issues with ON CONFLICT UPDATE and REINDEX CONCURRENTLY
|
| Список | pgsql-hackers |
Hello, On 2026-Jan-25, Mihail Nikalayeu wrote: > Hello, Álvaro! > > Fixes are in attachment. I think the comment message and comments are good > enough to explain the changes. Great, many thanks for this. The commit message looks quite good, but I decided to rewrite the comment in the code. What do you think of this? (There's also a typo fix for one of the previous commits) > Also, the second commit adds syscache for pg_inherites. I am not very > confident with it, but it feels correct to me. Hmm, I think a syscache on (inhrelid, inhseqno) is a bit weird. This might be okay, but I'm not sure, and I don't think we absolutely need this right now. That is to say, I'm not rejecting this, but I'm not going to pursue getting it pushed for now. > Another approach - put information about parents into [relcache] - I > can rebuild the patch that way. I think that change would be a larger revamp that I definitely don't want to touch at this time. > Also, for the first commit it is possible to create a batched version of > get_partition_ancestors (with the same snapshot for multiple indexes). Yeah, I've had such thoughts too, but I'd rather fix the bug in a reasonably non invasive way (which perhaps we can consider backpatching in some not-too-distant future); major rearchitecting like that can happen later without pressure. -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
Вложения
В списке pgsql-hackers по дате отправления: