| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Fixing code that ignores failure of XLogRecGetBlockTag |
| Date: | 2022-04-11 21:44:45 |
| Message-ID: | 635670.1649713485@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> On Tue, Apr 12, 2022 at 8:58 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Mon, Apr 11, 2022 at 2:20 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Munro | 2022-04-11 22:33:28 | Re: Is RecoveryConflictInterrupt() entirely safe in a signal handler? |
| Previous Message | Thomas Munro | 2022-04-11 21:16:12 | Re: Fixing code that ignores failure of XLogRecGetBlockTag |