Indeed, NOTICE is wrong because it would doom the transaction that sets the flag if it should be later PREPARED. I think that reporting the PIDs and the current activity of each process would be nice. DeadLoackReport() is using pgstat_get_backend_current_activity() to get the process activity.
Craig Ringer cr...@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
On Tue, Dec 02, 2014 at 11:17:43AM +0100, 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(...) calls with the NOTIFY
On 12/02/2014 06:17 PM, Olivier MATROT wrote: I was wondering if there was a log level in PostgreSQL that could tell me which query was the trigger of a doomed transaction. It's not necessarily possible to tell which *query* in another transaction caused the current one to fail. It might not
On 12/02/2014 06:17 PM, 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(...) calls with the NOTIFY level, each time