On 2017-11-09 12:55:30 -0500, Robert Haas wrote: > 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.
You can already pass arbitrary byteas to heap_page_items(), so I don't see how this'd change anything exposure-wise? Or are you thinking that users would continually do this with actual page contents and would be more likely to hit edge cases than if using pg_read_binary_file() or such (which obviously sees an out of date page)? Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers