diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2022-04-11 17:43:46 -0400 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2022-04-11 17:43:53 -0400 |
commit | bd037dc928dd126e5623117b2fe7633ec3fa7c40 (patch) | |
tree | b78ae993f860444b43e70e6c0f38aeec5d6ee383 /src/backend/access/gist/gistvacuum.c | |
parent | 9debd123483b970a53ba0e3de51c6234f3044df0 (diff) | |
download | postgresql-bd037dc928dd126e5623117b2fe7633ec3fa7c40.tar.gz postgresql-bd037dc928dd126e5623117b2fe7633ec3fa7c40.zip |
Make XLogRecGetBlockTag() throw error if there's no such block.
All but a few existing callers assume without checking that this
function succeeds. While it probably will, that's a poor excuse for
not checking. Let's make it return void and instead throw an error
if it doesn't find the block reference. Callers that actually need
to handle the no-such-block case must now use the underlying function
XLogRecGetBlockTagExtended.
In addition to being a bit less error-prone, this should also serve
to suppress some Coverity complaints about XLogRecGetBlockRefInfo.
While at it, clean up some inconsistency about use of the
XLogRecHasBlockRef macro: make XLogRecGetBlockTagExtended use
that instead of open-coding the same condition, and avoid calling
XLogRecHasBlockRef twice in relevant code paths. (That is,
calling XLogRecHasBlockRef followed by XLogRecGetBlockTag is now
deprecated: use XLogRecGetBlockTagExtended instead.)
Patch HEAD only; this doesn't seem to have enough value to consider
a back-branch API break.
Discussion: https://postgr.es/m/425039.1649701221@sss.pgh.pa.us
Diffstat (limited to 'src/backend/access/gist/gistvacuum.c')
0 files changed, 0 insertions, 0 deletions