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-29 00:25:30 |
Message-ID: | 670953.1627518330@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
improve-libpq-OOM-reporting-2.patch | text/x-diff | 3.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2021-07-29 00:52:08 | Re: Use WaitLatch for {pre, post}_auth_delay instead of pg_usleep |
Previous Message | Michael Paquier | 2021-07-28 23:49:17 | Re: CREATE SEQUENCE with RESTART option |