Re: pageinspect patch, for showing tuple data - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: pageinspect patch, for showing tuple data
Date
Msg-id 20150803183523.GL2441@postgresql.org
Whole thread Raw
In response to pageinspect patch, for showing tuple data  (Nikolay Shaplov <n.shaplov@postgrespro.ru>)
Responses Re: pageinspect patch, for showing tuple data  (Nikolay Shaplov <n.shaplov@postgrespro.ru>)
Re: pageinspect patch, for showing tuple data  (Nikolay Shaplov <n.shaplov@postgrespro.ru>)
List pgsql-hackers
Nikolay Shaplov wrote:

> This patch adds several new functions, available from SQL queries. All these 
> functions are based on heap_page_items, but accept slightly different 
> arguments and has one additional column at the result set:
> 
> heap_page_tuples - accepts relation name, and bulkno, and returns usual 
> heap_page_items set with additional column that contain snapshot of tuple data 
> area stored in bytea.

I think the API around get_raw_page is more useful generally.  You might
have table blocks stored in a bytea column for instance, because you
extracted from some remote server and inserted into a local table for
examination.  If you only accept relname/blkno, there's no way to
examine data other than blocks directly in the database dir, which is
limiting.

> There is also one strange function: _heap_page_items it is useless for 
> practical purposes. As heap_page_items it accepts page data as bytea, but also 
> get a relation name. It tries to apply tuple descriptor of that relation to 
> that page data. 

For BRIN, I added something similar (brin_page_items), but it receives
the index OID rather than name, and constructs a tuple descriptor to
read the data.  I think OID is better than name generally.  (You can
cast the relation name to regclass).

It's easy to misuse, but these functions are superuser-only, so there
should be no security issue at least.  The possibility of a crash
remains real, though, so maybe we should try to come up with a way to
harden that.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: ON CONFLICT DO UPDATE using EXCLUDED.column gives an error about mismatched types
Next
From: Tom Lane
Date:
Subject: Re: [sqlsmith] Failed assertion in joinrels.c