Re: [GENERAL] Serialization exception : Who else was involved?
Olivier MATROT wrote: > 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 ? First you should make this suggestion on the -hackers list; if you have a patch against HEAD, attach it. If you get positive or encouraging feedback, add the patch to the next commitfest. People who contribute code are also expected to review code. Read the Developer FAQ: https://wiki.postgresql.org/wiki/Developer_FAQ Another helpful article: https://wiki.postgresql.org/wiki/So,_you_want_to_be_a_developer%3F Yours, Laurenz Albe -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Serialization exception : Who else was involved?
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-ow...@postgresql.org [mailto:pgsql-general-ow...@postgresql.org] De la part de Olivier MATROT Envoyé : mardi 25 novembre 2014 13:00 À : pgsql-general@postgresql.org Objet : [GENERAL] Serialization exception : Who else was involved? 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.
[GENERAL] Serialization exception : Who else was involved?
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.
