Re: Corruption with duplicate primary key - Mailing list pgsql-hackers

From Alex Adriaanse
Subject Re: Corruption with duplicate primary key
Date
Msg-id CY4PR03MB269502786425690DA5B2EDBAA9370@CY4PR03MB2695.namprd03.prod.outlook.com
Whole thread Raw
In response to Re: Corruption with duplicate primary key  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
List pgsql-hackers
On Thu., December 12, 2019 at 5:25 PM, Tomas Vondra wrote:
>On Wed, Dec 11, 2019 at 11:46:40PM +0000, Alex Adriaanse wrote:
>>On Thu., December 5, 2019 at 5:45 PM, Tomas Vondra wrote:
>>> At first I thought maybe this might be due to collations changing and
>>> breaking the index silently. What collation are you using?
>>
>>We're using en_US.utf8. We did not make any collation changes to my
>>knowledge.
>
>Well, the idea was more that glibc got updated and the collations
>changed because of that (without PostgreSQL having a chance to even
>notice that).

Closing the loop on this, I've investigated this some more and it turns out this is exactly what happened. As you
suspected,the issue had nothing to do with pg_upgrade or PG12, but rather the glibc upgrade that was seen in Debian
Buster.The postgres:10 and postgres:11 images are based on Debian Stretch, whereas postgres:12 is based on Buster. 

When I kept the database on an older version of Postgres (10 or 11) but switched from the older Docker image to the
postgres:12or debian:buster(-slim) image, manually installing older Postgres packages inside those images, I saw index
corruptionthere too. 

Thanks for the input!

Alex


pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: aggregate crash
Next
From: Robert Haas
Date:
Subject: making the backend's json parser work in frontend code