|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Cc:||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:||Out-of-memory error reports in libpq|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
While cleaning out dead branches in my git repo, I came across an
early draft of what eventually became commit ffa2e4670 ("In libpq,
always append new error messages to conn->errorMessage"). I realized
that it contained a good idea that had gotten lost on the way to that
commit. Namely, let's reduce all of the 60-or-so "out of memory"
reports in libpq to calls to a common subroutine, and then let's teach
the common subroutine a recovery strategy for the not-unlikely
possibility that it fails to append the "out of memory" string to
conn->errorMessage. That recovery strategy of course is to reset the
errorMessage buffer to empty, hopefully regaining some space. We lose
whatever we'd had in the buffer before, but we have a better chance of
the "out of memory" message making its way to the user.
The first half of that just saves a few hundred bytes of repetitive
coding. However, I think that the addition of recovery logic is
important for robustness, because as things stand libpq may be
worse off than before for OOM handling. Before ffa2e4670, almost
all of these call sites did printfPQExpBuffer(..., "out of memory").
That would automatically clear the message buffer to empty, and
thereby be sure to report the out-of-memory failure if at all
possible. Now we might fail to report the thing that the user
really needs to know to make sense of what happened.
Therefore, I feel like this was an oversight in ffa2e4670,
and we ought to back-patch the attached into v14.
cc'ing the RMT in case they wish to object.
regards, tom lane
|Next Message||John W Higgins||2021-07-27 23:08:22||Re: Have I found an interval arithmetic bug?|
|Previous Message||Daniel Gustafsson||2021-07-27 22:37:47||Remove client-log from SSL test .gitignore|