Re: Bogus collation version recording in recordMultipleDependencies

From: Julien Rouhaud <rjuju123(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Bogus collation version recording in recordMultipleDependencies
Date: 2021-04-17 09:23:09
Message-ID: 20210417092309.vdmqiidn4ddhyoew@nol
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Apr 16, 2021 at 01:07:52PM -0400, Tom Lane wrote:
> I wrote:
> > ... or maybe not just yet. Andres' buildfarm critters seem to have
> > a different opinion than my machine about what the output of
> > collate.icu.utf8 ought to be. I wonder what the prevailing LANG
> > setting is for them, and which ICU version they're using.
>
> Oh, I bet it's "C.utf8", because I can reproduce the failure with that.
> This crystallizes a nagging feeling I'd had that you were misdescribing
> the collate.icu.utf8 test as not being run under --no-locale. Actually,
> it's only skipped if the encoding isn't UTF8, not the same thing.
> I think we need to remove the default-collation cases from that test too.

IIUC pg_regress --no-locale will call initdb --no-locale which force the locale
to C, and in that case pg_get_encoding_from_locale() does force SQL_ASCII as
encoding. But yes I clearly didn't think at all that you could set the various
env variables to C.utf8 which can then run the collate.icu.utf8 or linux.utf8
:(

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Julien Rouhaud 2021-04-17 09:24:43 Re: Bogus collation version recording in recordMultipleDependencies
Previous Message Japin Li 2021-04-17 07:35:17 Re: Truncate in synchronous logical replication failed