Re: UPSERT strange behavior

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: UPSERT strange behavior
Дата
Msg-id CAM3SWZQPj9Kdha8nv1uh_ONSY7p1eGc6uHLvT69n_2MrV9JUBw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: UPSERT strange behavior  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: UPSERT strange behavior  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: UPSERT strange behavior  (Konstantin Knizhnik <k.knizhnik@postgrespro.ru>)
Список pgsql-hackers
On Thu, Aug 25, 2016 at 11:49 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I think the point is that given the way he's set up the test case,
> there should be no duplicate violation in the plain unique index
> unless there is one in the arbiter index.  So assuming that INSERT
> tests the arbiter indexes first, there shouldn't be an error.
> Maybe it doesn't do that, but it seems like it would be a good idea
> if it did.

Oh, yeah. This is arguably an example of inference failing to infer
multiple unique indexes as arbiters. Inference could, in principle,
recognize that the second unique index is equivalent to the first, but
doesn't. (I don't think that it matters which order anything is tested
in, though, because not finding a dup value in the arbiter index does
not guarantee that there won't be one in the other index. There is no
locking when no conflict is initially found, and so no guarantees
here.)

Anyway, I don't have a lot of sympathy for this point of view, because
the scenario is completely contrived. You have to draw the line
somewhere.

-- 
Peter Geoghegan



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: increasing the default WAL segment size
Следующее
От: Tom Lane
Дата:
Сообщение: Re: UPSERT strange behavior