Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry on constraintviolation [and 2 more messages]
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry on constraintviolation [and 2 more messages] |
Дата | |
Msg-id | CA+TgmoaM0bqWnXzvvfKvS=orTsOednuUbWC2b8csUmf_=Eii2w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry on constraintviolation [and 2 more messages] (Kevin Grittner <kgrittn@gmail.com>) |
Список | 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
В списке pgsql-hackers по дате отправления: