Re: Out-of-memory error reports in libpq

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
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 21:37:24
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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?

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

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Smith 2021-07-28 23:08:23 Re: Replace l337sp34k in comments.
Previous Message Daniel Gustafsson 2021-07-28 21:09:57 Re: [PATCH] test/ssl: rework the sslfiles Makefile target