We have a Postgres 10 database that we recently upgraded to Postgres 12 using
pg_upgrade. We recently discovered that there are rows in one of the tables
that have duplicate primary keys:
record_loader=# \d loader.sync
Table "loader.sync"
Column |
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.
> 1) When you do the
On Mon, December 9, 2019 at 11:05 AM Finnerty, Jim wrote:
> If you have BEFORE triggers, and a BEFORE trigger signaled failure with
> RETURN NULL, then this is one known (and documented) issue that I think could
> cause the behavior you're reporting:
>
>
On Thu, December 5, 2019 at 5:34 PM Peter Geoghegan wrote:
> > We have a Postgres 10 database that we recently upgraded to Postgres 12
> > using pg_upgrade. We recently discovered that there are rows in one of the
> > tables that have duplicate primary keys:
>
> What's the timeline here? In
We have primary and hot standby databases running Postgres 11.3 inside Docker,
with their data directories bind-mounted to a reflink-enabled XFS filesystem.
The VM is running Debian's 4.19.16-1~bpo9+1 kernel inside an AWS EC2 instance.
I've seen TOAST corruption in one of the standby databases
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
>>> breaki
