Em qua., 28 de jul. de 2021 às 21:25, Tom Lane <tgl@sss.pgh.pa.us> escreveu:
I wrote: > Andres Freund <andres@anarazel.de> writes: >> Hm. It seems we should be able to guarantee that the recovery path can print >> something, at least in the PGconn case. Is it perhaps worth pre-sizing >> PGConn->errorMessage so it'd fit an error like this? >> But perhaps that's more effort than it's worth.
> Yeah. I considered changing things so that oom_buffer contains > "out of memory\n" rather than an empty string, but I'm afraid > that that's making unsupportable assumptions about what PQExpBuffers > are used for.
Actually, wait a minute. There are only a couple of places that ever read out the value of conn->errorMessage, so let's make those places responsible for dealing with OOM scenarios. That leads to a nicely small patch, as attached, and it looks to me like it makes us quite bulletproof against such scenarios.
It might still be worth doing the "pqReportOOM" changes to save a few bytes of code space, but I'm less excited about that now.
IMO, I think that "char *msg" is unnecessary, isn't it?
+ if (!PQExpBufferBroken(errorMessage)) + res->errMsg = pqResultStrdup(res, errorMessage->data); else - res->errMsg = NULL; + res->errMsg = libpq_gettext("out of memory\n");
