From: Tom Lane <tgl@sss.pgh.pa.us>
To: Nathan Bossart <nathandbossart@gmail.com>
cc: Gurjeet Singh <gurjeet@singh.im>,
        Postgres Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Fwd: Unprivileged user can induce crash by using an SUSET param
 in PGOPTIONS
In-reply-to: <20220721222900.GA3813377@nathanxps13>
References: 
 <CABwTF4XZvL4Mneo49MQZDBcRF+=8e2GOENViU3E-S9NGa8b90A@mail.gmail.com>
 <20220705174938.GB2566600@rfd.leadboat.com>
 <CABwTF4VEpwTHhRQ+q5MiC5ucngN-whN-PdcKeufX7eLSoAfbZA@mail.gmail.com>
 <335170.1658439851@sss.pgh.pa.us> <20220721222900.GA3813377@nathanxps13>
Comments: In-reply-to Nathan Bossart <nathandbossart@gmail.com>
	message dated "Thu, 21 Jul 2022 15:29:00 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <348145.1658446220.1@sss.pgh.pa.us>
Date: Thu, 21 Jul 2022 19:30:20 -0400
Message-ID: <348146.1658446220@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/348146.1658446220%40sss.pgh.pa.us>
Precedence: bulk

Nathan Bossart <nathandbossart@gmail.com> writes:
> +    StartTransactionCommand();
>      process_session_preload_libraries();
> +    CommitTransactionCommand();

Yeah, that way would avoid any questions about changing the order of
operations, but it seems like a mighty expensive solution: it's
adding a transaction to each backend start on the off chance that
(a) session_preload_libraries/local_preload_libraries is nonempty and
(b) the loaded libraries are going to do anything where it'd matter.
So that's why I thought of moving the call inside a pre-existing
transaction.

If we had to back-patch this into any released versions, I'd agree with
taking the performance hit in order to reduce the chance of side-effects.
But I think as long as we only have to do it in v15, it's not too late to
possibly cause some compatibility issues for extensions.

			regards, tom lane