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
