Re: BUG #18499: Reindexing spgist index concurrently triggers Assert("TransactionIdIsValid(state->myXid)")
От | Tom Lane |
---|---|
Тема | Re: BUG #18499: Reindexing spgist index concurrently triggers Assert("TransactionIdIsValid(state->myXid)") |
Дата | |
Msg-id | 3050563.1718580646@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #18499: Reindexing spgist index concurrently triggers Assert("TransactionIdIsValid(state->myXid)") (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: BUG #18499: Reindexing spgist index concurrently triggers Assert("TransactionIdIsValid(state->myXid)")
|
Список | pgsql-bugs |
Michael Paquier <michael@paquier.xyz> writes: > On Sun, Jun 16, 2024 at 06:52:52PM -0400, Tom Lane wrote: >> ... not sure there's a nice way for spginsert() to know whether it's >> being invoked in REINDEX CONCURRENTLY or a normal INSERT/UPDATE >> query. Can we trust indexInfo->ii_Concurrent for that? > I am not sure to understand the redirection part for spgist, but > except if I am missing something, we already rely on ii_Concurrent for > other index AMs like BRIN paths to check if we are dealing with a > concurrent build path or not. index_concurrently_build() is used > by both CIC and REINDEX CONCURRENTLY, where the flag is set after a > BuildIndexInfo(). Right. I was thinking that CIC wouldn't reach spginsert(), rather spgbuild(), but it does feel a bit rickety. A separate flag would be better. On the whole I'm inclined to stick with the patch as I have it. Maybe somebody would like to investigate this idea as an improvement for v18 or later. regards, tom lane
В списке pgsql-bugs по дате отправления: