From: | Don Seiler <don(at)seiler(dot)us> |
---|---|
To: | Jim Mlodgenski <jimmy76(at)gmail(dot)com> |
Cc: | pgsql-admin <pgsql-admin(at)postgresql(dot)org> |
Subject: | Re: Determining Indexes to Rebuild on new libc |
Date: | 2022-08-04 15:48:45 |
Message-ID: | CAHJZqBDcHoqmiZ_D=cr=WRS2tD2-w3Qvyn7Vcd7uVpYC60oO4w@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
On Thu, Aug 4, 2022 at 10:03 AM Jim Mlodgenski <jimmy76(at)gmail(dot)com> wrote:
>
> I don't think you can make that assumption with the UUID data. Try this
> simple example and you can see the sort order changes on the newer OS and
> can lead to duplicates on your primary key if you don't reindex after the
> upgrade.
>
> CREATE TABLE t1 (c1 varchar PRIMARY KEY);
> INSERT INTO t1 VALUES ('1-a'), ('1a'), ('1-aa');
> SELECT * FROM t1 ORDER BY c1;
>
>
Looks like you're right. Testing with PG 12.11 pgdg packages for their
respective Ubuntu versions:
18.04:
testdb=# SELECT * FROM t1 ORDER BY c1;
c1
------
1a
1-a
1-aa
(3 rows)
22.04:
testdb=# SELECT * FROM t1 ORDER BY c1;
c1
------
1-a
1a
1-aa
(3 rows)
So it looks like we'd have to rebuild any UUID index to be safe anyway,
which are used a lot for identifiers. *sadness intensifies*
--
Don Seiler
www.seiler.us
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Ribe | 2022-08-04 16:01:58 | Re: Determining Indexes to Rebuild on new libc |
Previous Message | Jim Mlodgenski | 2022-08-04 15:03:36 | Re: Determining Indexes to Rebuild on new libc |