Subject: [HACKERS] lock debug trace
This is an update to my previous patches for lock debugging, already applied
to the current sources. It adds some improvements in the output messages and
some more output in WaitOnLock(). I have used with success to trace a nasty
deadlock condition on pg_listener.
The following patches add to the backend a new debugging flag -K which prints
a debug trace of all locking operations on user relations (those with oid
greater than 20000). The code is compiled only if LOCK_MGR_DEBUG is defined,
so the patch should be harmless if not explicitly enabled.
I'm using the code to trace deadlock conditions caused by application queries
using the command "$POSTMASTER -D $PGDATA -o '-d 1 -K 1'.
The patches are for version 6.0 dated 970126.
Originally, I thought the problem was caused by a function that gets
called as a normal function where we want to return a value, and as a
signal handler where we need to have it accept a parameter (the signal
number) and it returns nothing, I was going to case the function name in
the signal call as (void (*)(int)).
Looking at all the source, it turns out this function only gets used as
a signal handler, so I set an int parameter and return void.
I have removed the Linux defines because they are not needed. BSD let
this sloppiness slide. Linux gave a compile error.
Submitted by: Bruce Momjian <maillist@candle.pha.pa.us>
In postgres95/src/backend/nodes/readfuncs, lines 1188 and 1189,
local_node->relname is taken to point to a NameType, while its
defined as a pointer to char. Both the casting to Name and the
call of namestrcpy should, IMHO, be changed appropriately (first
patch).
As far as I could see from the Linux signal header file,
a signal handler is declared as
typedef void (*__sighandler_t)(int);
Few changes to postgres95/src/backend/storage/lmgr/proc.c seem
appropriate to comply with this.
Finally, postgres95/src/bin/pg_version/pg_version.c defines
a function GetDataHome (by default, returning an integer)
and returns NULL in the function, which isn't an integer...
Submitted by: ernst.molitor@uni-bonn.de