Re: Crash issue in PG18.5 regression

From: Andres Freund <andres(at)anarazel(dot)de>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Cc: Álvaro Herrera <alvherre(at)kurilemu(dot)de>, "Masashi Kamura (Fujitsu)" <kamura(dot)masashi(at)fujitsu(dot)com>, "'pgsql-hackers(at)lists(dot)postgresql(dot)org'" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Jeff Davis <pgsql(at)j-davis(dot)com>
Subject: Re: Crash issue in PG18.5 regression
Date: 2026-08-11 16:55:18
Message-ID: v36ssaygf7grb3qzfsjhtdzi7kqd45ds56nyuf7gi5qjml4qbb@ezmfqzmhlrs2
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2026-08-11 12:41:49 +0300, Heikki Linnakangas wrote:
> On 11/08/2026 12:19, Heikki Linnakangas wrote:
> > I think the best fix is to make pg_strupper() in REL_18_STABLE also work
> > with the C locale. It's an accident waiting to happen if it doesn't.
> > (And same for all the other pg_str*() functions, of course)
>
> Like the attached.
>
> There's some code duplication: the strupper_c() function is essentially the
> same as asc_toupper(), and str_toupper() wouldn't really need to have the
> special case for C locale anymore, it could just rely on pg_strupper() now.
> But that's so in 'master' too, so I think cleaning that up should be left
> for a separate patch.

I wonder if we also ought to do something about the other uses of
pg_locale_t->info.lt in pg_locale_libc.c? That's at least strncoll_libc(),
strnxfrm_libc(). I think all the in-core callers guard them, but the
protection seems mighty far away in some cases.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2026-08-11 17:02:57 Re: Crash issue in PG18.5 regression
Previous Message Palak Chaturvedi 2026-08-11 16:07:31 Re: Better shared data structure management and resizable shared data structures