Re: Serialization exception : Who else was involved?
От | Kevin Grittner |
---|---|
Тема | Re: Serialization exception : Who else was involved? |
Дата | |
Msg-id | 847597156.1366317.1419866500367.JavaMail.yahoo@jws100201.mail.ne1.yahoo.com обсуждение исходный текст |
Ответ на | Re: Serialization exception : Who else was involved? (Craig Ringer <craig@2ndquadrant.com>) |
Список | pgsql-hackers |
Craig Ringer <craig@2ndquadrant.com> wrote: > I don't see how that'd necessarily correctly identify the > query/queries in the other tx that're involved, though. > > Perhaps I'm thinking in terms of more complicated serialization > failures? Yeah, it might be possible to provide useful information about specific conflicting queries in some cases, but I'm skeptical that it would be available in the majority of cases. In most cases you can probably identify one or two other transactions that are involved. In at least some cases you won't even have that. For one fun case to think about, see this example where a read-only transaction fails with on conflict with two already-committed transactions: https://wiki.postgresql.org/wiki/SSI#Rollover Also consider when there is a long-running transactions and SSI falls back to SLRU summarization. If we can find a way to provide some useful information in some cases without harming performance, that's fine as long as nobody expects that it will be available in all cases. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: