Andres Freund <andres@2ndquadrant.com> writes:
> Also: Man, trying to understand the guts of deadlock.c only made me
> understand how *friggin* expensive deadlock checking is. I'm really
> rather surprised that it only infrequently causes problems.
The reason for that is that we only run deadlock checking if something's
been waiting for at least one second, which pretty much takes it out
of any performance-relevant code pathway. I think it would be a serious
error to put any deadlock-checking-like behavior into mainline code.
Which probably means that Andres is right that teaching deadlock.c
about any new sources of deadlock is the way to approach this.
regards, tom lane