Re: Duplicate key violation on upsert

From: Matt Magoffin <postgresql(dot)org(at)msqr(dot)us>
To: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
Cc: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Duplicate key violation on upsert
Date: 2020-03-26 00:23:49
Message-ID: 65AECD9A-CE13-4FCB-9158-23BE62BB65DD@msqr.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general


> On 23/03/2020, at 1:10 PM, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> wrote:
>
> So the query is in the function solardatum.store_datum()?

>
> If so what is it doing?

Yes. This function first performs the INSERT INTO the solardatum.da_datum table that we’re discussing here; then it inserts into two different tables. If it helps, the actual SQL is available here:

https://github.com/SolarNetwork/solarnetwork-central/blob/4fa585929a5526187ade0e842c809837647c6a41/solarnet-db-setup/postgres/postgres-init-generic-datum-x-functions.sql#L203-L242

> And could you capture the values and pass them to a RAISE NOTICE?

It would take me some time to get that change deployed. If I was able to, what information do you think would be helpful here, e.g. that jdata_a is NULL or not, or something else?

The duplicate key violation occurs infrequently, and it does seem appropriate to drop the UNIQUE constraint on the da_datum_x_acc_idx given uniqueness is really only wanted on (node_id, ts, source_id). As long as I can confirm that query performance doesn’t decrease, I’d like to recreate the index without UNIQUE. Then I’m hoping this problem, whatever the cause, goes away.

— m@

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Bruce Momjian 2020-03-26 00:50:13 Re: PostgreSQL 13: native JavaScript Procedural Language support ?
Previous Message Chris Morris 2020-03-25 17:38:29 Re: PG 12: Partitioning across a FDW?