Re: Dupe Key Violations in Logical Replication with PKs in Place - Mailing list pgsql-admin

From Don Seiler
Subject Re: Dupe Key Violations in Logical Replication with PKs in Place
Date
Msg-id CAHJZqBBGOCdUeyz-38jHOJ0akxtsEispdPwpV77U_321+kpkqw@mail.gmail.com
Whole thread Raw
In response to Re: Dupe Key Violations in Logical Replication with PKs in Place  (Scott Ribe <scott_ribe@elevated-dev.com>)
List pgsql-admin
On Tue, Nov 14, 2023 at 12:02 PM Scott Ribe <scott_ribe@elevated-dev.com> wrote:
> On Nov 14, 2023, at 10:54 AM, Don Seiler <don@seiler.us> wrote:
>
> Well this looks to be human error/cause after all. I made the mistake of announcing the upcoming migration and one eager developer connected to the new/subscription DB and ran some inserts (also running them on the old/publication DB). The inserts were all in one transaction, and look to be responsible for all 3 of duplicate key incidents.

So this would be about the 2 billionth or so episode in the DBA series titled "shit happens" ;-) Glad you figured it out.

I'm not sure why his connection didn't show up in my PG logs. I log connects and disconnects but I don't see anything coming from our apps or VPN network CIDRs, that would have been an important lead early on.


--
Don Seiler
www.seiler.us

pgsql-admin by date:

Previous
From: Scott Ribe
Date:
Subject: Re: Dupe Key Violations in Logical Replication with PKs in Place
Next
From: Andres Freund
Date:
Subject: Re: pg_restore -L reordering of the statements does not work