Re: "Value locking" Wiki page

From: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, Peter Geoghegan <pg(at)heroku(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: "Value locking" Wiki page
Date: 2014-10-01 13:49:19
Message-ID: 542C065F.4080109@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 10/01/2014 04:31 PM, Simon Riggs wrote:
> On 1 October 2014 13:43, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> wrote:
>
>>> That does sound interesting, but I am concerned the semantics may cause
>>> issues.
>>>
>>> If I go to insert a row for 'UK' and find an existing row for
>>> 'Europe', do we really want to update the population of Europe to be
>>> the population of the UK, simply because the UK and Europe have an
>>> exclusion conflict?
>>
>> Clearly not, but you might want to insert the tuple to another table
>> instead, or skip it altogether. Or you might want to UPDATE Europe into
>> Continental Europe, and then insert the row for UK.
>
> Not trying to catch you out, just trying to make sure we don't make
> technical decisions based upon unachievable ideas.
>
> I can't see value in having upsert work against exclusion constraint
> indexes; thus this only needs to work for btrees, or similar exact
> indexes.

Well, if nothing else, it would be nice to fix the concurrency issue we
have with exclusion constraints today, which is that if two backends
insert the same value at the same time, they might both get an error,
even though you'd only need to abort one of them. That's a special case
of UPSERT if you squint a little.

- Heikki

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Gregory Smith 2014-10-01 13:58:02 Re: Time measurement format - more human readable
Previous Message Simon Riggs 2014-10-01 13:46:04 Re: "Value locking" Wiki page