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.

I'll see what I could come up with.

Thanks,
om

-----Message d'origine-----
De : Noah Misch [mailto:n...@leadboat.com] 
Envoyé : samedi 27 décembre 2014 10:51
À : Olivier MATROT
Cc : pgsql-hackers@postgresql.org
Objet : Re: Serialization exception : Who else was involved?

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 level, each time the 
> flag is set, compiled the code and give it a try.

> I would like to see this useful and simple addition in a future 
> version of PostgreSQL.
> Is it in the spirit of what is done when it comes to ease the work of 
> the developer ?
> May be the level I've chosen is not appropriate ?

I would value extra logging designed to help users understand the genesis of 
serialization failures.  A patch the community would adopt will probably have 
more complexity than your quick elog(NOTICE, ...) addition.  I don't have a 
clear picture of what the final patch should be, but the following are some 
thoughts to outline the problem space.  See [1] for an earlier discussion.
The logging done in DeadLockReport() is a good baseline; it would be best to 
consolidate a similar level of detail and report it all as part of the main 
serialization failure report.  That may prove impractical.  If transaction TA 
marks transaction TB's doom, TA can be long gone by the time TB reports its 
serialization failure.  TA could persist the details needed for that future 
error report, but that may impose costs out of proportion with the benefit.
If so, we can fall back on your original idea of emitting a message in the 
command that performs the flag flip.  That would need a DEBUG error level, 
though.  Sending a NOTICE to a client when its transaction dooms some other 
transaction would add noise in the wrong place.

Thanks,
nm

[1] 
http://www.postgresql.org/message-id/flat/AANLkTikF-CR-52nWAo2VG_348aTsK_+0i=chbpnqd...@mail.gmail.com


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to