| From: | Alex Adriaanse <alex(at)oseberg(dot)io> |
|---|---|
| To: | "Finnerty, Jim" <jfinnert(at)amazon(dot)com> |
| Cc: | "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Corruption with duplicate primary key |
| Date: | 2019-12-11 23:49:05 |
| Message-ID: | SN6PR03MB3598F20EE858DA6FD71EB75AA95A0@SN6PR03MB3598.namprd03.prod.outlook.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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:
>
> https://www.postgresql-archive.org/BEFORE-triggers-that-return-NULL-can-circumvent-referential-integrity-tt6056390.html#none
>
> It's hard to say if this is the cause or not, but if you have any BEFORE triggers that RETURN NULL, you might want to review the documentation very carefully.
We do have a BEFORE INSERT trigger, but it should never return NULL. This trigger INSERTs into a different table using an ON CONFLICT DO NOTHING clause and then does a RETURN NEW.
Alex
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2019-12-12 00:14:50 | Re: Runtime pruning problem |
| Previous Message | Alex Adriaanse | 2019-12-11 23:46:40 | Re: Corruption with duplicate primary key |