| From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
| Cc: | Noah Misch <noah(at)leadboat(dot)com>, Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: pgsql: Fix a couple of bugs in MultiXactId freezing |
| Date: | 2013-12-03 23:51:29 |
| Message-ID: | 20131203235129.GI19016@awork2.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers pgsql-hackers |
On 2013-12-03 19:55:40 -0300, Alvaro Herrera wrote:
> I added a new isolation spec to test this specific case, and noticed
> something that seems curious to me when that test is run in REPEATABLE
> READ mode: when the UPDATE is aborted, the concurrent FOR UPDATE gets a
> "can't serialize due to concurrent update", but when the UPDATE is
> committed, FOR UPDATE works fine. Shouldn't it happen pretty much
> exactly the other way around?
That's 247c76a989097f1b4ab6fae898f24e75aa27fc1b . Specifically the
DidCommit() branch in test_lockmode_for_conflict(). You forgot something
akin to
/* locker has finished, all good to go */
if (!ISUPDATE_from_mxstatus(status))
return HeapTupleMayBeUpdated;
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2013-12-04 04:00:43 | pgsql: Fix whitespace |
| Previous Message | Alvaro Herrera | 2013-12-03 23:14:37 | Re: pgsql: Fix a couple of bugs in MultiXactId freezing |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Joshua D. Drake | 2013-12-04 00:05:52 | Re: Why we are going to have to go DirectIO |
| Previous Message | Tom Lane | 2013-12-03 23:37:23 | ruleutils vs. empty targetlists |