Re: pageinspect patch, for showing tuple data
От | Alvaro Herrera |
---|---|
Тема | Re: pageinspect patch, for showing tuple data |
Дата | |
Msg-id | 20150803183523.GL2441@postgresql.org обсуждение исходный текст |
Ответ на | pageinspect patch, for showing tuple data (Nikolay Shaplov <n.shaplov@postgrespro.ru>) |
Ответы |
Re: pageinspect patch, for showing tuple data
Re: pageinspect patch, for showing tuple data |
Список | 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 по дате отправления: