From: | Peter Geoghegan <pg(at)heroku(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | hlinnaka <hlinnaka(at)iki(dot)fi>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)2ndquadrant(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Bruce Momjian <bruce(at)momjian(dot)us>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
Subject: | Re: INSERT ... ON CONFLICT IGNORE (and UPDATE) 3.0 |
Date: | 2015-03-23 17:34:25 |
Message-ID: | CAM3SWZTx1+w5LXMmfUsJo6K-o9EaygXR1nbZv3sVoJzPVPbhXw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Mar 19, 2015 at 1:02 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> I think this is pretty lousy. The reasons why the user wants things
> that way is because they created a UNIQUE index and it got bloated
> somehow with lots of dead tuples. So they made a new UNIQUE index on
> the same column and then they're planning to do a DROP INDEX
> CONCURRENTLY on the old one, which is maybe even now in progress. And
> now they start getting duplicate key failures, the avoidance of which
> was their whole reason for using UPSERT in the first place. If I were
> that user, I'd report that as a bug, and if someone told me that it
> was intended behavior, I'd say "oh, so you deliberately designed this
> feature to not work some of the time?".
>
> ISTM that we need to (1) decide which operator we're using to compare
> and then (2) tolerate conflicts in every index that uses that
> operator. In most cases there will only be one, but if there are
> more, so be it.
On reflection, I see your point. I'll try and do something about this too.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Sawada Masahiko | 2015-03-23 17:39:33 | Re: Auditing extension for PostgreSQL (Take 2) |
Previous Message | Andres Freund | 2015-03-23 17:30:23 | Re: logical column ordering |