Re: INSERT ... ON CONFLICT IGNORE (and UPDATE) 3.0
От | Peter Geoghegan |
---|---|
Тема | Re: INSERT ... ON CONFLICT IGNORE (and UPDATE) 3.0 |
Дата | |
Msg-id | CAM3SWZTx1+w5LXMmfUsJo6K-o9EaygXR1nbZv3sVoJzPVPbhXw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: INSERT ... ON CONFLICT IGNORE (and UPDATE) 3.0 (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
On Thu, Mar 19, 2015 at 1:02 PM, Robert Haas <robertmhaas@gmail.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
В списке pgsql-hackers по дате отправления: