Re: pageinspect patch, for showing tuple data
От | Nikolay Shaplov |
---|---|
Тема | Re: pageinspect patch, for showing tuple data |
Дата | |
Msg-id | 14862871.BNXbXbsvcj@nataraj-amd64 обсуждение исходный текст |
Ответ на | Re: pageinspect patch, for showing tuple data (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Список | pgsql-hackers |
В письме от 3 августа 2015 15:35:23 Вы написали: > 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. Hmm... may be you are right. I'll try to change it would take raw page and OID. -- Nikolay Shaplov Postgres Professional: http://www.postgrespro.com Russian Postgres Company
В списке pgsql-hackers по дате отправления: