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
