From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: bug in pageinspect's "tuple data" feature |
Date: | 2020-11-24 15:16:45 |
Message-ID: | 20201124151645.GA11584@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2020-Nov-24, Michael Paquier wrote:
> On Mon, Nov 23, 2020 at 09:11:26AM +0200, Heikki Linnakangas wrote:
> > On 21/11/2020 21:32, Alvaro Herrera wrote:
> >> This is pretty unhelpful; it would be better not to try to print the
> >> data instead of dying. With that, at least you can know where the
> >> problem is.
> >>
> >> This was introduced in d6061f83a166 (2015). Proposed patch to fix it
> >> (by having the code print a null "data" instead of dying) is attached.
> >
> > Null seems misleading. Maybe something like "invalid", or print a warning?
Good idea, thanks.
> How did you get into this state to begin with?
The data was corrupted for whatever reason. I don't care why or how, I
just need to fix it. If the data isn't corrupted, then I don't use
pageinspect in the first place.
> get_raw_page() uses ReadBufferExtended() which gives some level of
> protection already, so shouldn't it be better to return an ERROR with
> ERRCODE_DATA_CORRUPTED and the block involved?
What would I gain from doing that? It's even more unhelpful, because it
is intentional rather than accidental.
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2020-11-24 15:20:15 | Re: Terminate the idle sessions |
Previous Message | Alvaro Herrera | 2020-11-24 15:11:35 | Re: About adding a new filed to a struct in primnodes.h |