Re: Promise index tuples for UPSERT

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
Cc: Peter Geoghegan <pg(at)heroku(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)2ndquadrant(dot)com>
Subject: Re: Promise index tuples for UPSERT
Date: 2014-10-06 12:05:58
Message-ID: CA+U5nMJZKJKzriNvJL0_qJBwGODtCydQC8RV54m4ejuF+iLUvw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 3 October 2014 11:54, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> wrote:

> Simon's approach would actually pass that test case just fine. It inserts
> the (promise) index tuple first, and heap tuple only after that. It will
> fail the test case with more than one unique index, however.

Please explain what you mean by "fail" here?

My understanding of what you're saying is that if

* we have a table with >1 unique index
* and we update the values of the uniquely index columns (e.g. PK update)
* on both of the uniquely indexed column sets
then we get occaisonal deadlocks, just as we would do using current
UPDATE/INSERT.

Is their a business use case that requires that? (Or exactly what you
meant, if that isn't it?)

My view is if we are going to base the whole design on this point,
then we need to have it very clearly accessible for all to understand.

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2014-10-06 12:06:53 Re: pg_receivexlog --status-interval add fsync feedback
Previous Message Michael Paquier 2014-10-06 11:49:11 Re: pg_receivexlog and replication slots