Re: pageinspect: add tuple_data_record()

В письме от 16 октября 2018 19:17:20 пользователь Andres Freund написал:
> Hi,
>
> On 2018-10-16 22:05:28 -0400, James Coleman wrote:
> > > I don't think it's entirely safe to do so for invisible rows. The toast
> > > references could be reused, constraints be violated, etc. So while I
> > > could have used this several times before, it's also very likely a good
> > > way to cause trouble. It'd probably be ok to just fetch the binary
> > > value of the columns, but detoasting sure ain't ok.

> > Wouldn’t that be equally true for the already existing toast option to
> > tuple_data_split()?

> Yes. Whoever added that didn't think far enough. Teodor, Nikolay?

I did compleatly got the question... The question is it safe to split tuple
record into array of raw bytea? It is quite safe from my point of view. We
use only data that is inside the tuple, and info from pg_catalog that
describes the tuple structure. So we are not affected if for example toast
table were cleaned by vacuum. If you try to deTOAST data when TOAST table were
already overwritten by new data, you can get some trouble...

> > Is “unsafe” here something that would lead to a crash? Or just returning
> > invalid data?

I think that you should try and see. Find a way to make postgres vacuum toast
table, and overwrite it with some new data, but keep tuple in heap page
untouched. Then try to deTOAST old data and see what happened. (Hint: it is
good to turn off compression for your data to be TOASTed, so you can just look
into toast-file in binary mode and get an idea what in it now)

======
>> Summary:
>> The new function tuple_data_record() parallels the existing
>> tuple_data_split() function, but instead of returning a bytea array of raw
>> attribute heap values, it returns a row type of the relation being
>> examined.

I find this approach a bit wrong. pageinspect is about viewing data in raw
mode, not about looking at the tuples that were deleted. It can be used for
this task, but it has other main purpose.

I would suggest instead of automatically detoast and uncompress actual data, I
would add functions that:

1. Checks if TOAST id is valid, and data can be fetched
2. Fetches that data and print it in raw mode
3. Says if binary data is compressed varlen data
4. Uncompress binary data and return it as another binary data
5. Convert binary data into string.

or something like that. This would be more according to the pageinspect
spirit, as I see it.

Than using these functions you can write pure sql wrapper that do what you
really want.

--
Do code for fun.