Re: Segfault while using an array domain - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Segfault while using an array domain
Date
Msg-id 19089.1448825732@sss.pgh.pa.us
Whole thread Raw
In response to Segfault while using an array domain  (Emre Hasegeli <emre@hasegeli.com>)
List pgsql-hackers
Emre Hasegeli <emre@hasegeli.com> writes:
> [ SQL function in a domain constraint doesn't work ]

Hm, looks like I broke this in 8abb3cda0.  Should have learned by now
that long-lived caching of ExprState trees is dangerous.  The proximate
cause of the problem is that execQual.c is executing an expression state
tree that's held by the typcache, but it is using an ecxt_per_query_memory
context that's only of query lifespan.  We end up with pointers into that
context from the typcache's state tree, which of course soon become
dangling pointers.

It's possible that we could temporarily change ecxt_per_query_memory
during ExecEvalCoerceToDomain to point to the context holding the state
trees, but that sounds pretty risky; at the very least there's a risk of
meant-to-be-query-lifespan allocations turning into session-lifespan
memory leakage.

Probably the best idea is to give up on caching the ExprState trees for
domain constraints this way.  We can still cache the Expr trees and
thereby avoid pg_constraint catalog reads, but we'll have to pay an
ExecInitExpr pass per query.

At some point I'd really like to find a way to keep ExprState trees
longer; this is a problem for plpgsql performance too.  But it's too
late in the 9.5 cycle to tackle that problem.

Or we could revert 8abb3cda0 altogether for the time being, but I hate to
do that because it was a correctness improvement not just a performance
tweak.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: silent data loss with ext4 / all current versions
Next
From: Peter Geoghegan
Date:
Subject: Making the C collation less inclined to abort abbreviation