Re: Out-of-memory error reports in libpq - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Out-of-memory error reports in libpq
Date
Msg-id 606767.1627508244@sss.pgh.pa.us
Whole thread Raw
In response to Re: Out-of-memory error reports in libpq  (Andres Freund <andres@anarazel.de>)
Responses Re: Out-of-memory error reports in libpq  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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?

Forgot to address this.  Right now, the normal situation is that
PGConn->errorMessage is "pre sized" to 256 bytes, because that's
what pqexpbuffer.c does for all PQExpBuffers.  So unless you've
overrun that, the question is moot.  If you have, and you got
an OOM in trying to expand the PQExpBuffer, then pqexpbuffer.c
will release what it has and substitute the "oom_buffer" empty
string.  If you're really unlucky you might then not be able
to allocate another 256-byte buffer, in which case we end up
with an empty-string result.  I don't think it's probable,
but in a multithread program it could happen.

> 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.

For now, I'm content if it's not worse than v13.  We've not
heard a lot of complaints in this area.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: [PATCH] test/ssl: rework the sslfiles Makefile target
Next
From: Peter Smith
Date:
Subject: Re: Replace l337sp34k in comments.