Re: bug in pageinspect's "tuple data" feature - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: bug in pageinspect's "tuple data" feature
Date
Msg-id 20201124151645.GA11584@alvherre.pgsql
Whole thread Raw
In response to Re: bug in pageinspect's "tuple data" feature  (Michael Paquier <michael@paquier.xyz>)
List 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.



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: About adding a new filed to a struct in primnodes.h
Next
From: "David G. Johnston"
Date:
Subject: Re: Terminate the idle sessions