Re: BUG #12330: ACID is broken for unique constraints
От | Kevin Grittner |
---|---|
Тема | Re: BUG #12330: ACID is broken for unique constraints |
Дата | |
Msg-id | 350083331.929532.1419619081068.JavaMail.yahoo@jws100139.mail.ne1.yahoo.com обсуждение исходный текст |
Ответ на | Re: BUG #12330: ACID is broken for unique constraints (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #12330: ACID is broken for unique constraints
Re: BUG #12330: ACID is broken for unique constraints |
Список | pgsql-hackers |
Tom Lane <tgl@sss.pgh.pa.us> wrote: > Just for starters, a 40XXX error report will fail to provide the > duplicated key's value. This will be a functional regression, Not if, as is normally the case, the transaction is retried from the beginning on a serialization failure. Either the code will check for a duplicate (as in the case of the OP on this thread) and they won't see the error, *or* the the transaction which created the duplicate key will have committed before the start of the retry and you will get the duplicate key error. > I think an appropriate response to these complaints is to fix the > documentation to point out that duplicate-key violations may also > be worthy of retries. > but I see no mention of the issue in chapter 13.) I agree that's the best we can do for stable branches, and worth doing. It would be interesting to hear from others who have rely on serializable transactions in production environments about what makes sense to them. This is probably the wrong list to find such people directly; but I seem to recall Josh Berkus has a lot of clients who do. Josh? Any opinion on this thread? -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: