Re: Segfault while using an array domain
От | Tom Lane |
---|---|
Тема | Re: Segfault while using an array domain |
Дата | |
Msg-id | 19089.1448825732@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Segfault while using an array domain (Emre Hasegeli <emre@hasegeli.com>) |
Список | 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 по дате отправления: