Re: Out-of-memory error reports in libpq
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@lists.postgresql.org, Michael Paquier <michael@paquier.xyz>,
Alvaro Herrera <alvherre@alvh.no-ip.org>, Peter Geoghegan <pg@bowt.ie>
Date: 2021-07-29T00:25:30Z
Lists: pgsql-hackers
Attachments
- improve-libpq-OOM-reporting-2.patch (text/x-diff) patch
I wrote: > 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? >> 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
Commits
-
Improve libpq's handling of OOM during error message construction.
- 514b4c11d247 15.0 landed
- 43f1d2ab361c 14.0 landed
-
In libpq, always append new error messages to conn->errorMessage.
- ffa2e4670123 14.0 cited