Andres Freund <andres@anarazel.de> writes: > On 2022-11-21 12:52:01 -0500, Robert Haas wrote: >> On Mon, Nov 21, 2022 at 12:35 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> Why in the world is get_raw_page() marked as parallel safe? >>> It clearly isn't, given this restriction.
> It's somewhat sad to add this restriction - I've used get_raw_page() (+ > other functions) to scan a whole database for a bug. IIRC that actually > did end up using parallelism, albeit likely not very efficiently. > Don't really have a better idea though.
Me either.
> It may be worth inventing a framework where a function could analyze its > arguments (presumably via prosupport) to determine the degree of > parallel safety, but this doesn't seem sufficient reason...
Maybe, but in this example you could only decide you were parallel safe if the argument is an OID constant, which'd be pretty limiting.
If I were trying to find a better fix I'd be looking for ways for parallel workers to be able to read the parent's temp tables. (Perhaps that could tie in with the blue-sky discussion we had the other day about allowing autovacuum on temp tables??)
I don't suppose we want to just document the fact that these power-user non-core functions are unable to process temporary tables safely without first disabling parallelism for the session.
