Re: Out-of-memory error reports in libpq
Ranier Vilela <ranier.vf@gmail.com>
From: Ranier Vilela <ranier.vf@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@anarazel.de>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
Michael Paquier <michael@paquier.xyz>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Peter Geoghegan <pg@bowt.ie>
Date: 2021-07-29T01:03:29Z
Lists: pgsql-hackers
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");
>
> regards, tom lane
>
>
Commits
-
Improve libpq's handling of OOM during error message construction.
- 514b4c11d247 15.0 landed
- 43f1d2ab361c 14.0 landed
-
In libpq, always append new error messages to conn->errorMessage.
- ffa2e4670123 14.0 cited