Improve libpq's handling of OOM during error message construction.
Commit ffa2e4670 changed libpq so that multiple error reports
occurring during one operation (a connection attempt or query)
are accumulated in conn->errorMessage, where before new ones
usually replaced any prior error. At least in theory, that makes
us more vulnerable to running out of memory for the errorMessage
buffer. If it did happen, the user would be left with just an
empty-string error report, which is pretty unhelpful.
We can improve this by relying on pqexpbuffer.c's existing "broken
buffer" convention to track whether we've hit OOM for the current
operation's error string, and then substituting a constant "out of
memory" string in the small number of places where the errorMessage
is read out.
While at it, apply the same method to similar OOM cases in
pqInternalNotice and pqGetErrorNotice3.
Back-patch to v14 where ffa2e4670 came in. In principle this could
go back further; but in view of the lack of field reports, the
hazard seems negligible in older branches.
Discussion: https://postgr.es/m/530153.1627425648@sss.pgh.pa.us
Branch
------
REL_14_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/43f1d2ab361ccbd5ba8b53578fd4bcea9a6344a6
Modified Files
--------------
src/interfaces/libpq/fe-connect.c | 8 +++++++
src/interfaces/libpq/fe-exec.c | 42 ++++++++++++++++++++++++-------------
src/interfaces/libpq/fe-protocol3.c | 15 +++++++++----
src/interfaces/libpq/libpq-int.h | 2 +-
4 files changed, 48 insertions(+), 19 deletions(-)