On 10/06/2014 03:05 PM, Simon Riggs wrote:
On 3 October 2014 11:54, Heikki Linnakangas <hlinnakan...@vmware.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?

I meant that the test case will sometimes deadlock, and some transactions will therefore be rolled back.

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

Right. To be precise: you don't need to update both of the columns in the same transaction, it's enough that some of the concurrent transactions update one column, while other transactions update the other column.

Is their a business use case that requires that?

I don't know. Conceivably any use case where you have two unique constraints to begin with.

- Heikki

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to