Looking closer, I realized that my proposed change in RestoreGUCState
is unnecessary, because guc_free() is already permissive about being
passed a NULL. That leaves us with one live bug in
get_explain_guc_options, two probably-unreachable hazards in
check_GUC_init and
Hi,
Seems that Tom's patch cannot be applied to the current master branch.
I just re-generate the patch for others to play with.
On 11/2/23, Nathan Bossart wrote:
> On Wed, Nov 01, 2023 at 10:39:04PM -0400, Tom Lane wrote:
>> Nathan Bossart writes:
>>> What if we disallowed NULL string GUCs in
On Wed, Nov 01, 2023 at 10:39:04PM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> What if we disallowed NULL string GUCs in v17?
>
> Well, we'd need to devise some other solution for hacks like the
> one used by timezone_abbreviations (see comment in
> check_timezone_abbreviations). I think
Nathan Bossart writes:
> On Wed, Nov 01, 2023 at 09:57:18PM -0400, Tom Lane wrote:
>> After digging around for a bit, I think part of the problem is a lack
>> of a clearly defined spec for what should happen with NULL string GUCs.
> What if we disallowed NULL string GUCs in v17?
Well, we'd need
On Wed, Nov 01, 2023 at 09:57:18PM -0400, Tom Lane wrote:
> I wrote:
>> Hmm ... if we're doing it ourselves, I suppose we've got to consider
>> it supported :-(. But I'm still wondering how many seldom-used
>> code paths didn't get the message. An example here is that this
>> could lead to
Thank you Tom!
Your comment
"NULL doesn't have semantics that are visibly different from an empty
string" is exactly what I want to confirm :-)
On 11/2/23, Tom Lane wrote:
> I wrote:
>> Hmm ... if we're doing it ourselves, I suppose we've got to consider
>> it supported :-(. But I'm still
I wrote:
> Hmm ... if we're doing it ourselves, I suppose we've got to consider
> it supported :-(. But I'm still wondering how many seldom-used
> code paths didn't get the message. An example here is that this
> could lead to GetConfigOptionResetString returning NULL, which
> I think is outside
Xing Guo writes:
> There're extensions that set their boot_val to NULL. E.g., postgres_fdw
Hmm ... if we're doing it ourselves, I suppose we've got to consider
it supported :-(. But I'm still wondering how many seldom-used
code paths didn't get the message. An example here is that this
could
Hi Tom,
There're extensions that set their boot_val to NULL. E.g., postgres_fdw (
https://github.com/postgres/postgres/blob/4210b55f598534db9d52c4535b7dcc777dda75a6/contrib/postgres_fdw/option.c#L582),
plperl (
Xing Guo writes:
> Thanks for your comments. I have updated the patch accordingly.
I'm leery of accepting this patch, as I see no reason that we
should consider it valid for an extension to have a string GUC
with a boot_val of NULL.
I realize that we have a few core GUCs that are like that, but
Hi Aleksander and Junwang,
Thanks for your comments. I have updated the patch accordingly.
Best Regards,
Xing
On Wed, Nov 1, 2023 at 7:44 PM Aleksander Alekseev
wrote:
> Hi,
>
> > > I found that there's a nullable pointer being passed to strcmp() and
> > > can make the server crash. It
Hi,
> > I found that there's a nullable pointer being passed to strcmp() and
> > can make the server crash. It can be reproduced on the latest master
> > branch by crafting an extension[1]. Patch for fixing it is attatched.
> >
> > [1] https://github.com/higuoxing/guc_crash/tree/pg
Thanks for
On Wed, Nov 1, 2023 at 5:25 PM Xing Guo wrote:
>
> Hi hackers,
>
> I found that there's a nullable pointer being passed to strcmp() and
> can make the server crash. It can be reproduced on the latest master
> branch by crafting an extension[1]. Patch for fixing it is attatched.
>
> [1]
Hi hackers,
I found that there's a nullable pointer being passed to strcmp() and
can make the server crash. It can be reproduced on the latest master
branch by crafting an extension[1]. Patch for fixing it is attatched.
[1] https://github.com/higuoxing/guc_crash/tree/pg
--
Best Regards,
Xing
14 matches
Mail list logo
