Re: pgsql: Harden new test case against force_parallel_mode = regress.

On Fri, Mar 3, 2023 at 11:37 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> The workers were failing at startup, eg (from [1]):
>
> +ERROR: role "regress_psql_user" does not exist
> +CONTEXT: while setting parameter "session_authorization" to "regress_psql_user"
>
> Maybe this says that worker startup needs to install the snapshot before
> doing any catalog accesses? Anyway, I'd be happy to revert this test
> hack if you care to make the case work.

Oh, that's interesting (and sad). A parallel worker has a "startup
transaction" that is used to restore library and GUC state, and then
after that transaction commits, it starts up a new transaction that
uses the same snapshot and settings as the transaction in the parallel
leader. So the problem here is that the startup transaction can't see
the uncommitted work of some unrelated (as far as it knows)
transaction, and that prevents restoring the session_authorization
GUC.

That startup transaction has broken stuff before, and it would be nice
to get rid of it. Unfortunately, I don't remember right now why we
need it in the first place. I'm fairly sure that if you load the
library and GUC state without any transaction, that doesn't work,
because a bunch of important processing gets skipped. And I think if
you try to do those things in the "real" transaction that fails for
some reason too, maybe that there's no guarantee that all the relevant
GUCs can be changed at that point, but I'm fuzzy on the details at the
moment.

So I don't know how to fix this right now, but thanks for the details.

--
Robert Haas
EDB: http://www.enterprisedb.com