Re: BUG #16378: Invalid memory access on interrupting CLUSTER after CREATE TEMP TABLE

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: exclusion(at)gmail(dot)com
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #16378: Invalid memory access on interrupting CLUSTER after CREATE TEMP TABLE
Date: 2020-04-19 18:11:37
Message-ID: 4545.1587319897@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

PG Bug reporting form <noreply(at)postgresql(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2020-04-19 18:29:31 BUG #16380: documentation: host[no]gssenc vs. address/IP-address/IP-mask fields
Previous Message David Kubecka 2020-04-19 18:09:44 Re: Possibly misleading documentation of Template Patterns for Date/Time Formatting