Re: pgsql: Prevent instability in contrib/pageinspect's regression test.

On Mon, Nov 21, 2022 at 1:12 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

> 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.

David J.