Re: Out-of-memory error reports in libpq

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: 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-28 19:55:52
Message-ID: 20210728195552.qlve2apuo7w56fim@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2021-07-27 18:40:48 -0400, Tom Lane wrote:
> The first half of that just saves a few hundred bytes of repetitive
> coding. However, I think that the addition of recovery logic is
> important for robustness, because as things stand libpq may be
> worse off than before for OOM handling.

Agreed.

> Before ffa2e4670, almost all of these call sites did
> printfPQExpBuffer(..., "out of memory"). That would automatically
> clear the message buffer to empty, and thereby be sure to report the
> out-of-memory failure if at all possible. Now we might fail to report
> the thing that the user really needs to know to make sense of what
> happened.

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.

> +void
> +pqReportOOMBuffer(PQExpBuffer errorMessage)
> +{
> + const char *msg = libpq_gettext("out of memory\n");

I should probably know this, but I don't. Nor did I quickly find an answer. I
assume gettext() reliably and reasonably deals with OOM?

Looking in the gettext code I'm again scared by the fact that it takes locks
during gettext (because of stuff like erroring out of signal handlers, not
OOMs).

It does look like it tries to always return the original string in case of
OOM. Although the code is quite maze-like, so it's not easy to tell..

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2021-07-28 20:05:10 Re: alter table set TABLE ACCESS METHOD
Previous Message Andres Freund 2021-07-28 19:28:00 Re: needless complexity in StartupXLOG