Re: EDB builds Postgres 13 with an obsolete ICU version

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Dave Page <dpage(at)pgadmin(dot)org>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Daniel Verite <daniel(at)manitou-mail(dot)org>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: EDB builds Postgres 13 with an obsolete ICU version
Date: 2020-08-11 12:58:30
Message-ID: CABUevExeBagfdWnvpj6X8co=8Fh6+kBUWtSWMS+rd=saErkXpw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Aug 4, 2020 at 11:42 AM Dave Page <dpage(at)pgadmin(dot)org> wrote:

>
>
> On Tue, Aug 4, 2020 at 10:29 AM Magnus Hagander <magnus(at)hagander(dot)net>
> wrote:
>
>> On Tue, Aug 4, 2020 at 10:07 AM Dave Page <dpage(at)pgadmin(dot)org> wrote:
>>
>>>
>>>
>>> On Tue, Aug 4, 2020 at 1:04 AM Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>>>
>>>> On Mon, Aug 3, 2020 at 08:56:06PM +0200, Daniel Verite wrote:
>>>> > Hi,
>>>> >
>>>> > As a follow-up to bug #16570 [1] and other previous discussions
>>>> > on the mailing-lists, I'm checking out PG13 beta for Windows
>>>> > from:
>>>> > https://www.enterprisedb.com/postgresql-early-experience
>>>> > and it ships with the same obsolete ICU 53 that was used
>>>> > for PG 10,11,12.
>>>> > Besides not having the latest Unicode features and fixes, ICU 53
>>>> > ignores the BCP 47 tags syntax in collations used as examples
>>>> > in Postgres documentation, which leads to confusion and
>>>> > false bug reports.
>>>> > The current version is ICU 67.
>>>> >
>>>> > I don't see where the suggestion to upgrade it before the
>>>> > next PG release should be addressed but maybe some people on
>>>> > this list do know or have the leverage to make it happen?
>>>>
>>>> Well, you can ask EDB about this, but perhaps the have kept the same ICU
>>>> version so indexes will not need to be reindexed.
>>>>
>>>
>>> Correct - updating ICU would mean a reindex is required following any
>>> upgrade, major or minor.
>>>
>>> I would really like to find an acceptable solution to this however as it
>>> really would be good to be able to update ICU.
>>>
>>
>> It certainly couldn't and shouldn't be done in a minor.
>>
>> But doing so in v13 doesn't seem entirely unreasonable, especially given
>> that I believe we will detect the requirement to reindex thanks to the
>> versioning, and not just start returning invalid results (like, say, with
>> those glibc updates).
>>
>> Would it be possible to have the installer even check if there are any
>> icu indexes in the database. If there aren't, just put in the new version
>> of icu. If there are, give the user a choice of the old version or new
>> version and reindex?
>>
>
> That would require fairly large changes to the installer to allow it to
> login to the database server (whether that would work would be dependent on
> how pg_hba.conf is configured), and also assumes that the ICU ABI hasn't
> changed between releases. It would also require some hacky renaming of
> DLLs, as they have the version number in them.
>

I assumed it had code for that stuff already. Mainly because I assumed it
supported doing pg_upgrade, which requires similar things no?

>
> The chances of designing, building and testing that thoroughly before v13
> is released is about zero I'd say.
>

Yeah, I can see how it would be for 13 -- unfortunately. But I definitely
think it's something that should go high on the list of things to get fixed
for 14.

//Magnus

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Bapat 2020-08-11 13:06:03 Re: Can I test Extended Query in core test framework
Previous Message Asim Praveen 2020-08-11 11:55:05 Re: SyncRepLock acquired exclusively in default configuration