Hello, I pushed the logs to the DEBUG5 level with no luck. So I decided to take a look at the code. Serialization conflict detection is done in src/backend/storage/lmgr/predicate.c, where transactions that are doomed to fail are marked as such with the SXACT_FLAG_DOOMED flag. I simply added elog(NOTIFY,...) calls with the DEBUG1 level, each time the flag is set, compiled the code and give it a try. The results are amazing for me, because this simple modification allows me to see which query is marking other running transactions to fail. Without this information, this is really difficult to understand what’s going on and, eventualy, modify my program to make my transactions run successfully more often. What is the correct way to suggest this improvement for a future version of PostgreSQL ? Regards. Olivier. De : pgsql-general-owner@xxxxxxxxxxxxxx [mailto:pgsql-general-owner@xxxxxxxxxxxxxx] De la part de Olivier MATROT I’m using PostgreSQL 9.2.8 on Windows x64. When a transaction as SERIALIZABLE isolation level is failing, is there a way to know which connection(s), thus transaction(s), were involved in the overall process ? I'm working on an accounting database. I know that we should retry the transaction, this is what we do. I've encountered an issue where a transaction has to be run 10 times to succeed on a busy system. There should be a serious problem here. I'm wondering if there is a configuration parameter that would allow the system to tell in the exception detail the other connections involved in the failure. The Postgresql wiki on SSI has no such information. Thanks is advance. Olivier. |
