From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: pgsql: Harden new test case against force_parallel_mode = regress.
In-reply-to: <CA+TgmobbA4gC103oSaFw+M7-ivmOMXRLAEx3Lwk+2asB92=4sg@mail.gmail.com>
References: <E1pXri2-001aid-6W@gemulon.postgresql.org> <CA+TgmoY-dsB-6GyF8q+V0T5+0Gbw0cT6TE7_8SsnESeUHZpnZQ@mail.gmail.com> <2478846.1677861476@sss.pgh.pa.us> <CA+TgmobbA4gC103oSaFw+M7-ivmOMXRLAEx3Lwk+2asB92=4sg@mail.gmail.com>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
	message dated "Fri, 03 Mar 2023 12:40:32 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <2504510.1677865602.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Fri, 03 Mar 2023 12:46:42 -0500
Message-ID: <2504511.1677865602@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/2504511.1677865602%40sss.pgh.pa.us>
Precedence: bulk

Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Mar 3, 2023 at 11:37=E2=80=AFAM Tom Lane <tgl@sss.pgh.pa.us> wro=
te:
>> +ERROR:  role "regress_psql_user" does not exist
>> +CONTEXT:  while setting parameter "session_authorization" to "regress_=
psql_user"

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

Got it.

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

Couldn't we install the leader's snapshot into both transactions?

			regards, tom lane