From: | Heikki Rauhala <heikki(dot)rauhala(at)reaktor(dot)fi> |
---|---|
To: | Peter Geoghegan <pg(at)heroku(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-bugs <pgsql-bugs(at)postgresql(dot)org>, Miko Kiiski <miko(dot)kiiski(at)reaktor(dot)com> |
Subject: | Re: "insert [...] on conflict" hangs on conflict on an unmentioned gist index |
Date: | 2016-07-05 11:44:13 |
Message-ID: | 94DC7388-ED07-4B4E-8494-A8AA17D7ED11@reaktor.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
> On 4.7.2016, at 20:35, Peter Geoghegan <pg(at)heroku(dot)com> wrote:
>
> On Mon, Jul 4, 2016 at 9:38 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Nah, I take that back --- I was expecting this to be handled somewhere
>> else than it is. It looks like the actual cause is just sloppy
>> handling of noDupErr in ExecInsertIndexTuples; the attached fixes it
>> for me.
>
> I agree that that's all this was; it's uncommon to specify an
> exclusion constraint by name with DO NOTHING, so we didn't catch this
> until now.
Thanks for the quick response! I tested the patch with the more complex query that initially brought this up, which is more like:
insert into gist_test (bar, foo) values ('baz', 'foo')
on conflict on constraint gist_test_bar_unique
do update set foo = excluded.foo;
The patch works as expected also for that case.
Best regards,
- Heikki.
From | Date | Subject | |
---|---|---|---|
Next Message | Timur Luchkin | 2016-07-05 11:47:41 | Too slow "Analyze" for the table with data in Thai language |
Previous Message | Peter Geoghegan | 2016-07-04 17:35:46 | Re: "insert [...] on conflict" hangs on conflict on an unmentioned gist index |