Hi,
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:
> > I wrote:
> > > Andres Freund <and...@anarazel.de> writes:
> > >> Looks like a chunk of the buildfarm doesn't like this - presumably
> > >> because
> > >> they use force_parallel_mode = regress. Seems ok to just force that to
> > >> off in
> > >> this test?
> >
> > > Ugh ... didn't occur to me to try that. I'll take a look.
> >
> > Hmm, so the problem is:
> >
> > SELECT octet_length(get_raw_page('test1', 'main', 0)) AS main_0;
> > ERROR: cannot access temporary tables during a parallel operation
> >
> > Why in the world is get_raw_page() marked as parallel safe?
> > It clearly isn't, given this restriction.
>
> I suspect that restriction was overlooked when evaluating the marking
> of this function.
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.
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...
Greetings
Andres Freund
