On Mon, Nov 21, 2022 at 1:12 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > Andres Freund <and...@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 <t...@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.
David J.
