Hi Adrian,
> On 22 Sep 2024, at 18:53, Adrian Klaver wrote:
>
> https://www.postgresql.org/docs/17/release-17.html#RELEASE-17-HIGHLIGHTS
>
> Add a builtin platform-independent collation provider (Jeff Davis)
>
> This supports C and C.UTF-8 collations.
I must admit that I haven't read the read
On 2024-09-22 09:53:58 -0700, Adrian Klaver wrote:
> On 9/22/24 09:48, Paul Förster wrote:
> > Then I strongly suggest that the PostgreSQL developers develop a
> > fail safe sorting mechanism that holds for generations of locale
> > changes.
>
> https://www.postgresql.org/docs/17/release-17.html#R
On 9/22/24 12:53, Adrian Klaver wrote:
On 9/22/24 09:48, Paul Förster wrote:
Hi Joe
On 22. Sep, 2024, at 15:47, Joe Conway wrote:
Note that moving to ICU might improve things, but there are similar potential
issues with ICU as well. The trick there would be to get your OS distro
provider t
On 9/22/24 09:48, Paul Förster wrote:
Hi Joe
On 22. Sep, 2024, at 15:47, Joe Conway wrote:
Note that moving to ICU might improve things, but there are similar potential
issues with ICU as well. The trick there would be to get your OS distro
provider to maintain the same ICU version across m
Hi Ron,
> On 22. Sep, 2024, at 16:11, Ron Johnson wrote:
>
> The real question is why nobody notices it in other RDBMSs like Oracle, SQL
> Server and MySQL.
The answer is simple for Oracle: It includes a whole zoo of locale mappings and
uses each one as it is needed. This is one of the many t
Hi Joe
> On 22. Sep, 2024, at 15:47, Joe Conway wrote:
>
> Note that moving to ICU might improve things, but there are similar potential
> issues with ICU as well. The trick there would be to get your OS distro
> provider to maintain the same ICU version across major versions of the
> distro,
Am Sun, Sep 22, 2024 at 02:59:34PM +0100 schrieb Shaheed Haque:
> I've been working on Unix-like systems for decades and though I thought I
> understood most of the issues to do with i18n/l10n, I've only just started
> using Postgres and I don't understand is why these changes ONLY seem to
> affec
Shaheed,
How often do you sort words in text editors?
How often do you have your text editor care whether the word you just typed
is the *only* instance of that word in the document?
Not too often. So... yes, we ignore the problem.
The real question is why nobody notices it in other RDBMSs like
I've been working on Unix-like systems for decades and though I thought I
understood most of the issues to do with i18n/l10n, I've only just started
using Postgres and I don't understand is why these changes ONLY seem to
affect Postgres. Or is it more that it also affects text editors and the
like,
On 9/21/24 15:19, Paul Foerster wrote:
I already expressed the idea of changing all locales to ICU. The
problem there is that I'd have to create new instances and then move
each database individually. I wish I could convert already running
databases… This also takes time. Still, I think I'm going
Hi Peter,
> On 21 Sep 2024, at 00:33, Peter J. Holzer wrote:
>
> I don't use SLES but I would expect it to have an RPM for it.
>
> If you have any test machine which you can upgrade before the production
> servers (and given the amount of data and availability requirements you
> have, I really
On 2024-09-19 20:12:13 +0200, Paul Foerster wrote:
> Hi Peter,
> > On 19 Sep 2024, at 19:43, Peter J. Holzer wrote:
> >
> > I wrote a small script[1] which prints all unicode code points and a few
> > selected[2] longer strings in order. If you run that before and after
> > the upgrade and the ou
Hi Joe,
> On 19 Sep 2024, at 20:09, Joe Conway wrote:
>
> See my thread-adjacent email, but suffice to say that if there are collation
> differences that do affect your tables/data, and you allow any inserts or
> updates, you may wind up with corrupted data (e.g. duplicate data in your
> othe
Hi Peter,
> On 19 Sep 2024, at 19:43, Peter J. Holzer wrote:
>
> I wrote a small script[1] which prints all unicode code points and a few
> selected[2] longer strings in order. If you run that before and after
> the upgrade and the output doesn't change, you are probably be fine.
> (It checks on
On 9/19/24 13:56, Paul Foerster wrote:
On 19 Sep 2024, at 17:14, Tom Lane wrote:
Maybe. We don't really track glibc changes, so I can't say for sure,
but it might be advisable to reindex indexes on string columns.
Advisable is a word I undfortunately can't do much with. We have
terabytes and
Hi Joe,
> On 19 Sep 2024, at 19:07, Joe Conway wrote:
>
> Every glibc major version change potentially impacts the sorting of some
> strings, which would require reindexing. Whether your actual data trips into
> any of these changes is another matter.
>
> You could check by doing something eq
Hi Tom,
> On 19 Sep 2024, at 17:14, Tom Lane wrote:
>
> No, I wouldn't expect that to be necessary.
I was hoping one of the pros would say that. 🤣
> Maybe. We don't really track glibc changes, so I can't say for sure,
> but it might be advisable to reindex indexes on string columns.
Advisabl
Hi Adrian,
> On 19 Sep 2024, at 17:00, Adrian Klaver wrote:
>
> I would take a look at:
>
> https://wiki.postgresql.org/wiki/Locale_data_changes
>
> It refers to the glibc 2.8 change in particular, but includes some generic
> tips that could prove useful.
>
>
> The glibc change log below mi
On 2024-09-19 16:37:41 +0200, Paul Foerster wrote:
> we have SLES 15.5 which has glibc 2.31. Our admin told us that he's
> about to install the SLES 15.6 update which contains glibc 2.38.
>
> I have built our PostgreSQL software from source on SLES 15.5, because
> we have some special requirements
On 9/19/24 13:07, Joe Conway wrote:
On 9/19/24 11:14, Tom Lane wrote:
Paul Foerster writes:
we have SLES 15.5 which has glibc 2.31. Our admin told us that
he's about to install the SLES 15.6 update which contains glibc
2.38.
2) Does the glibc update have any impact?
Maybe. We don't really
On 9/19/24 11:14, Tom Lane wrote:
Paul Foerster writes:
we have SLES 15.5 which has glibc 2.31. Our admin told us that
he's about to install the SLES 15.6 update which contains glibc
2.38.
2) Does the glibc update have any impact?
Maybe. We don't really track glibc changes, so I can't say
Paul Foerster writes:
> we have SLES 15.5 which has glibc 2.31. Our admin told us that he's about to
> install the SLES 15.6 update which contains glibc 2.38.
> I have built our PostgreSQL software from source on SLES 15.5, because we
> have some special requirements which the packages cannot fu
On 9/19/24 07:37, Paul Foerster wrote:
Hi,
we have SLES 15.5 which has glibc 2.31. Our admin told us that he's about to
install the SLES 15.6 update which contains glibc 2.38.
I have built our PostgreSQL software from source on SLES 15.5, because we have
some special requirements which the pa
Hi,
we have SLES 15.5 which has glibc 2.31. Our admin told us that he's about to
install the SLES 15.6 update which contains glibc 2.38.
I have built our PostgreSQL software from source on SLES 15.5, because we have
some special requirements which the packages cannot fulfill. So I have
questio
24 matches
Mail list logo
