On Fri, Mar 3, 2023 at 11:37 AM Tom Lane <t...@sss.pgh.pa.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
