On Thu, Nov 9, 2017 at 12:49 PM, Andres Freund <and...@anarazel.de> wrote: > Occasionally, when debugging issues, I find it quite useful to be able > to do a heap_page_items() on a page that's actually locked exclusively > concurrently. E.g. investigating the recent multixact vacuuming issues, > it was very useful to attach a debugger to one backend to step through > freezing, and display the page in another session. > > Currently the locking in get_raw_page_internal() prevents that. If it's > an option defaulting to off, I don't see why we couldn't allow that to > skip locking the page's contents. Obviously you can get corrupted > contents that way, but we already allow to pass arbitrary stuff to > heap_page_items(). Since pinning wouldn't be changed, there's no danger > of the page being moved out from under us.
heap_page_items() is, if I remember correctly, not necessarily going to tolerate malformed input very well - I think that's why we restrict all of these functions to superusers. So using it in this way would seem to increase the risk of a server crash or other horrible misbehavior. Of course if we're just dev-testing that doesn't really matter. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers