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.
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@postgresql.org [mailto:pgsql-general-owner@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.
Import Notes
Resolved by subject fallback
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