On Thu, Jul 21, 2022 at 05:39:35PM -0700, Gurjeet Singh wrote:
> One notable side effect of this change is that
> process_session_preload_libraries() is now called _before_ we
> SetProcessingMode(NormalProcessing). Which means any database access
> performed by _PG_init() of an extension will be do
On Thu, Jul 21, 2022 at 4:35 PM Gurjeet Singh wrote:
> I like the idea of performing library initialization in
> InitPostgres(), as it performs the first transaction of the
> connection, and because of the libraries' ability to gin up new GUC
> variables that might need special handling, and also
On Thu, Jul 21, 2022 at 07:30:20PM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> +StartTransactionCommand();
>> process_session_preload_libraries();
>> +CommitTransactionCommand();
>
> Yeah, that way would avoid any questions about changing the order of
> operations, but it seem
On Thu, Jul 21, 2022 at 3:29 PM Nathan Bossart wrote:
>
> On Thu, Jul 21, 2022 at 05:44:11PM -0400, Tom Lane wrote:
> > Right. So there are basically two things we could do about this:
> >
> > 1. set_config_option could decline to call pg_parameter_aclcheck
> > if not IsTransactionState(), instea
On Thu, Jul 21, 2022 at 2:44 PM Tom Lane wrote:
>
> Gurjeet Singh writes:
> > While poking at plperl's GUC in an internal discussion, I was able to
> > induce a crash (or an assertion failure in assert-enabled builds) as
> > an unprivileged user.
> > My investigation so far has revealed that the
Nathan Bossart 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
On Thu, Jul 21, 2022 at 05:44:11PM -0400, Tom Lane wrote:
> Right. So there are basically two things we could do about this:
>
> 1. set_config_option could decline to call pg_parameter_aclcheck
> if not IsTransactionState(), instead failing the assignment.
> This isn't a great answer because it w
Gurjeet Singh writes:
> While poking at plperl's GUC in an internal discussion, I was able to
> induce a crash (or an assertion failure in assert-enabled builds) as
> an unprivileged user.
> My investigation so far has revealed that the code path for the
> following condition has never been tested
On Wed, Jul 20, 2022 at 07:31:47PM -0700, Gurjeet Singh wrote:
> Moving the report from security to -hackers on Noah's advice. Since
> the function(s) involved in the crash are not present in any of the
> released versions, it is not considered a security issue.
>
> I can confirm that this is repr
Moving the report from security to -hackers on Noah's advice. Since
the function(s) involved in the crash are not present in any of the
released versions, it is not considered a security issue.
I can confirm that this is reproducible on the latest commit on
master, 3c0bcdbc66. Below is the origina
10 matches
Mail list logo
