Hi, On 2023-01-05 13:21:54 +1300, Thomas Munro wrote: > Right, I contemplated variations on that theme. I'd be willing to > code something like that to kick the tyres, but it seems like it would > make back-patching more painful? We're trying to fix bugs here...
I think we need to accept that this mess can't be fixed in the back branches. I'd rather get a decent fix sometime in PG16 than a crufty fix in PG 17 that we then backpatch a while later. > Deciding to proceed with #6 (palloc) wouldn't mean we can't eventually > also implement two phase/soft CFI() when we have a potential user, so > I don't really get the painted-into-a-corner argument. I think that's a fair point. > However, it's all moot if the #6 isn't good enough on its own merits > independent of other hypothetical future users (eg if the per regex_t > MemoryContext overheads are considered too high and can't be tuned > acceptably). I'm not too worried about that, particularly because it looks like it'd not be too hard to lower the overhead further. Arguably allocating memory outside of mcxt.c is actually a bad thing independent of error handing, because it's effectively "invisible" to our memory-usage-monitoring facilities. Greetings, Andres Freund
