Re: [OSSTEST PATCH 0/1] PostgreSQL db: Retry on constraint violation [and 2 more messages]
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Kevin Grittner <kgrittn@gmail.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>,
Ian Jackson <ian.jackson@eu.citrix.com>, Thomas Munro <thomas.munro@enterprisedb.com>, xen-devel@lists.xenproject.org, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2016-12-14T14:42:48Z
Lists: pgsql-hackers
On Wed, Dec 14, 2016 at 9:40 AM, Kevin Grittner <kgrittn@gmail.com> wrote: > On Wed, Dec 14, 2016 at 8:27 AM, Robert Haas <robertmhaas@gmail.com> wrote: >> But even after that fix, at the least, you'll still be able to >> demonstrate the same problem by trapping serialization_failure rather >> than unique_constraint. > > I hope not; the "doomed" flag associated with a serializable > transaction should cause another attempt to cancel the transaction > at every subsequent opportunity, including commit. While we're > digging into bugs in this area it wouldn't hurt (as I said in my > prior post) to confirm that this is being handled everywhere it > should be, but I'd be kinda surprised if it wasn't. Oh, hmm. So you're saying that if I begin a subtransaction, read some data that causes a serialization anomaly, and then rollback the subtransaction, my toplevel transaction is now doomed? If so, then isn't that a counterexample to my proposition that a read-only transaction can't be cancelled at commit time? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Commits
-
Back-patch fcff8a575198478023ada8a48e13b50f70054766 as a bug fix.
- bed2a0b06ba5 9.5.6 landed
- 60314e28eb02 9.2.20 landed
- 5d80171adace 9.3.16 landed
- 4b9d466c1408 9.4.11 landed
-
Detect SSI conflicts before reporting constraint violations
- fcff8a575198 9.6.0 cited
-
Initial MVCC code.
- 3f7fbf85dc5b 7.1.1 cited