Re: BUG #16378: Invalid memory access on interrupting CLUSTER after CREATE TEMP TABLE
От | Tom Lane |
---|---|
Тема | Re: BUG #16378: Invalid memory access on interrupting CLUSTER after CREATE TEMP TABLE |
Дата | |
Msg-id | 4545.1587319897@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | BUG #16378: Invalid memory access on interrupting CLUSTER after CREATE TEMP TABLE (PG Bug reporting form <noreply@postgresql.org>) |
Ответы |
Re: BUG #16378: Invalid memory access on interrupting CLUSTER after CREATE TEMP TABLE
|
Список | pgsql-bugs |
PG Bug reporting form <noreply@postgresql.org> writes: > The following script: > ... > leads to a cassert-enabled server crash with the following messages in the > log (for the master branch): Hm, I can get a crash here without valgrind, as long as it's a cassert build. We're accessing a list that's been thrown away by memory context cleanup, so this results: TRAP: FailedAssertion("IsOidList(list)", File: "list.c", Line: 678) The timing is a bit finicky, but no more so than you report for the valgrind case. The difficulty is that the pendingReindexedIndexes list is kept in some transaction-local context, so it gets flushed during the transaction abort that is the first step of proc_exit processing. But the static pointer to it is still set, causing big problems if we do any system catalog accesses later --- like, say, while dropping the session's temp tables. One idea would be to keep the list in TopMemoryContext, but that feels like a band-aid solution. I think more likely what we ought to do is stop trying to use a PG_TRY in reindex_relation to drive cleanup, and instead hook ResetReindexPending into transaction abort processing honestly. I wonder how many other uses of PG_TRY have similar issues? It's not really obvious that this is an unsafe coding pattern. regards, tom lane
В списке pgsql-bugs по дате отправления: