Re: Fixing code that ignores failure of XLogRecGetBlockTag - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Fixing code that ignores failure of XLogRecGetBlockTag
Date
Msg-id 635670.1649713485@sss.pgh.pa.us
Whole thread Raw
In response to Re: Fixing code that ignores failure of XLogRecGetBlockTag  (Thomas Munro <thomas.munro@gmail.com>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Fixing code that ignores failure of XLogRecGetBlockTag
Next
From: Thomas Munro
Date:
Subject: Re: Is RecoveryConflictInterrupt() entirely safe in a signal handler?