Re: Out-of-memory error reports in libpq

From: Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Michael Paquier <michael(at)paquier(dot)xyz>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Peter Geoghegan <pg(at)bowt(dot)ie>
Subject: Re: Out-of-memory error reports in libpq
Date: 2021-07-29 01:03:29
Message-ID: CAEudQArbO-H5pS9DvvkkTqArVDEwzVG3KyJ31EJKYHro-Y533Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Em qua., 28 de jul. de 2021 às 21:25, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> escreveu:

> I wrote:
> > Andres Freund <andres(at)anarazel(dot)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
>
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2021-07-29 01:49:55 Re: Failed transaction statistics to measure the logical replication progress
Previous Message Michael Paquier 2021-07-29 00:57:30 Re: Emit namespace in post-copy output