| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Geoghegan <pg(at)heroku(dot)com> |
| Cc: | postgresql2(at)realityexists(dot)net, pgsql-bugs(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: [BUGS] BUG #13148: Unexpected deferred EXCLUDE constraint violation on derived table |
| Date: | 2015-05-11 16:47:59 |
| Message-ID: | 20150511164759.GQ12950@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs pgsql-hackers |
Hi,
On 2015-05-10 16:01:53 -0400, Tom Lane wrote:
> The cause of the problem seems to be that the UPDATE performs a HOT update
> of the new tuple, leaving in this case a dead tuple at (0,2) that is HOT
> updated by (0,3). When unique_key_recheck() is invoked for (0,2), it
> believes, correctly, that it has to perform the recheck anyway ... but it
> tells check_exclusion_constraint that the check is being performed for
> (0,2). So the index search inside check_exclusion_constraint finds the
> live tuple at (0,3) and thinks that is a conflict.
Heh, it's curious that this wasn't found up until now. I also wonder if
this might be related to the spurious violations Peter G. has been
observing...
> The attached patch seems to fix the problem without breaking any existing
> regression tests, but I wonder if anyone can see a hole in it.
Looks good to me.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2015-05-11 19:25:44 | Re: [BUGS] BUG #13148: Unexpected deferred EXCLUDE constraint violation on derived table |
| Previous Message | Bruce Momjian | 2015-05-11 15:46:25 | Re: BUG #12730: pg_dump produces trailing spaces |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2015-05-11 16:54:37 | Re: multixacts woes |
| Previous Message | Bruce Momjian | 2015-05-11 16:16:32 | Re: initdb start server recommendation |