Horton

Thread

Commits

  1. Make XLogRecGetBlockTag() throw error if there's no such block.

  1. Fixing code that ignores failure of XLogRecGetBlockTag

    Tom Lane <tgl@sss.pgh.pa.us> — 2022-04-11T18:20:21Z

    Currently, XLogRecGetBlockTag has 41 callers, of which only four
bother to check the function's result.  The remainder take it on
faith that they got valid data back, and many of them will
misbehave in seriously nasty ways if they didn't.  (This point
was drawn to my attention by a Coverity complaint.)

I think we should make this a little less fragile.  Since we
already have XLogRecGetBlockTagExtended, I propose that callers
that need to handle the case of no-such-block must use that,
while XLogRecGetBlockTag throws an error.  The attached patch
fixes that up, and also cleans up some random inconsistency
about use of XLogRecHasBlockRef().

			regards, tom lane

  2. Re: Fixing code that ignores failure of XLogRecGetBlockTag

    Robert Haas <robertmhaas@gmail.com> — 2022-04-11T20:57:47Z

    On Mon, Apr 11, 2022 at 2:20 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Currently, XLogRecGetBlockTag has 41 callers, of which only four
> bother to check the function's result.  The remainder take it on
> faith that they got valid data back, and many of them will
> misbehave in seriously nasty ways if they didn't.  (This point
> was drawn to my attention by a Coverity complaint.)
>
> I think we should make this a little less fragile.  Since we
> already have XLogRecGetBlockTagExtended, I propose that callers
> that need to handle the case of no-such-block must use that,
> while XLogRecGetBlockTag throws an error.  The attached patch
> fixes that up, and also cleans up some random inconsistency
> about use of XLogRecHasBlockRef().

Looks reasonable.

-- 
Robert Haas
EDB: http://www.enterprisedb.com

  3. Re: Fixing code that ignores failure of XLogRecGetBlockTag

    Thomas Munro <thomas.munro@gmail.com> — 2022-04-11T21:16:12Z

    On Tue, Apr 12, 2022 at 8:58 AM Robert Haas <robertmhaas@gmail.com> wrote:
> On Mon, Apr 11, 2022 at 2:20 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Currently, XLogRecGetBlockTag has 41 callers, of which only four
> > bother to check the function's result.  The remainder take it on
> > faith that they got valid data back, and many of them will
> > misbehave in seriously nasty ways if they didn't.  (This point
> > was drawn to my attention by a Coverity complaint.)
> >
> > I think we should make this a little less fragile.  Since we
> > already have XLogRecGetBlockTagExtended, I propose that callers
> > that need to handle the case of no-such-block must use that,
> > while XLogRecGetBlockTag throws an error.  The attached patch
> > fixes that up, and also cleans up some random inconsistency
> > about use of XLogRecHasBlockRef().
>
> Looks reasonable.

+1

  4. Re: Fixing code that ignores failure of XLogRecGetBlockTag

    Tom Lane <tgl@sss.pgh.pa.us> — 2022-04-11T21:44:45Z

    Thomas Munro <thomas.munro@gmail.com> writes:
> On Tue, Apr 12, 2022 at 8:58 AM Robert Haas <robertmhaas@gmail.com> wrote:
>> On Mon, Apr 11, 2022 at 2:20 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> I think we should make this a little less fragile.  Since we
>>> already have XLogRecGetBlockTagExtended, I propose that callers
>>> that need to handle the case of no-such-block must use that,
>>> while XLogRecGetBlockTag throws an error.  The attached patch
>>> fixes that up, and also cleans up some random inconsistency
>>> about use of XLogRecHasBlockRef().

>> Looks reasonable.

> +1

Pushed, thanks for looking.

			regards, tom lane