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
