Re: pageinspect: add tuple_data_record()

From: Andres Freund <andres(at)anarazel(dot)de>
To: James Coleman <jtc331(at)gmail(dot)com>
Cc: "dhyan(at)nataraj(dot)su" <dhyan(at)nataraj(dot)su>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Teodor Sigaev <teodor(at)sigaev(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pageinspect: add tuple_data_record()
Date: 2018-10-17 17:20:51
Message-ID: 20181017172051.pz5cmyozq6jva346@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2018-10-17 13:14:17 -0400, James Coleman wrote:
> > It's far from only toast that could be problematic here.
> >
>
> Do you have an example in mind? Wouldn’t the tuples have to be corrupted in
> some way to have problems with being interpreted as a datum? Or are you
> thinking very old tuples with a radically different structure to be causing
> the problem?

There's plenty ways it can go horribly wrong. Let's start with something
simple:

BEGIN;
ALTER TABLE ... ADD COLUMN blarg INT;
INSERT ... (blag) VALUES (132467890);
ROLLBACK;

ALTER TABLE ... ADD COLUMN blarg TEXT;

If you now read the table with your function you'll see a dead row that
will re-interpret a int datum as a text datum. Which in all likelyhood
will crash the server.

And yes, it's more likely to break with your patch, but I think the
current *split* function is dangerous too, and shouldn't have been added
without *A LOT* more attention to issues like this.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Larry Rosenman 2018-10-17 17:29:34 Peripatus/failures
Previous Message James Coleman 2018-10-17 17:14:17 Re: pageinspect: add tuple_data_record()