| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Tiago Babo <tiago(dot)babo(at)gmail(dot)com>, pgsql-bugs(at)postgresql(dot)org |
| Subject: | Re: BUG #14526: no unique or exclusion constraint matching the ON CONFLICT |
| Date: | 2017-02-07 19:34:09 |
| Message-ID: | CAH2-WznCD95BT2MiYvbXqNm79f7CDqkhidpiWQMpqoScw6brsA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Tue, Feb 7, 2017 at 10:54 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> That makes the question less about why it fails and more about why it
> seems to sometimes work. It shouldn't, at least not with this set of
> indexes and this query.
Agreed.
Log output from Tiago's system, with debug_print_parse = on,
debug_print_plan = on, and debug_print_rewritten = on might tell us
some more. If Tiago can enable those at a time that catches the
successful execution of the query (where inference mysteriously
works), we'd have a good chance of understanding what's up. (This is
probably something to be done quite selectively in production.)
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2017-02-07 20:30:28 | Re: BUG #14531: server process (PID 12714) was terminated by signal 11: Segmentation fault |
| Previous Message | Tiago Babo | 2017-02-07 19:33:59 | Re: BUG #14526: no unique or exclusion constraint matching the ON CONFLICT |