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.

Pointed out by:" Tatsuo Ishii <t-ishii@sra.co.jp>

from a #define to a run-time option '-e'

Man page was updated to reflect new option

Some compilers recognize this error.

In particular, no more compiled-in default for PGDATA or LIBDIR.  Commands
that need them need either invocation options or environment variables.
PGPORT default is hardcoded as 5432, but overrideable with options or
environment variables.

Pointed out by: wieck@sapserv.debis.de

If I have introduced any syntax errors with this, I will patch them in
the morning, and Marc will have a good laugh.

execute an sql function containing an utility command (create, notify, ...).
The bug is part in the planner, which returns a number of plans different
than the number of commands if there are utility commands in the query, and
in part in the function executor which assumes that all commands are normal
query commands and causes a SIGSEGV trying to execute commands without plan.

Submitted by: Massimo Dal Zotto <dz@cs.unitn.it>

The problem is that the function arguments are not considered as possible key
candidates for index scan and so only a sequential scan is possible inside
the body of a function.  I have therefore made some patches to the optimizer
so that indices are now used also by functions.  I have also moved the plan
debug message from pg_eval to pg_plan so that it is printed also for plans
genereated for function execution.  I had also to add an index rescan to the
executor because it ignored the parameters set in the execution state, they
were flagged as runtime variables in ExecInitIndexScan but then never used
by the executor so that the scan were always done with any key=1. Very odd.
This means that an index rescan is now done twice for each function execution
which uses an index, the first time when the index scan is initialized and
the second when the actual function arguments are finally available for the
execution.  I don't know what is the cost of an double index scan but I
suppose it is anyway less than the cost of a full sequential scan, at leat
for large tables. This is my patch, you must also add -DINDEXSCAN_PATCH in
Makefile.global to enable the changes.

Submitted by: Massimo Dal Zotto <dz@cs.unitn.it>

-Kurt

I've enclosed two patches.  The first affects Solaris compilability.  The
bug stems from netdb.h (where MAXHOSTNAMELEN is defined on a stock
system).  If the user has installed the header files from BIND 4.9.x,
there will be no definition of MAXHOSTNAMELEN.  The patch will, if all
else fails, try to include <arpa/nameser.h> and set MAXHOSTNAMELEN to
MAXDNAME, which is 256 (just like MAXHOSTNAMELEN on a stock system).

The second patch adds aliases for "ISNULL" to "IS NULL" and likewise for
"NOTNULL" to "IS NOT NULL".  I have not removed the postgres specific
ISNULL and NOTNULL.  I noticed this on the TODO list, and figured it would
be easy to remove.

The full semantics are:
        [ expression IS NULL ]
        [ expression IS NOT NULL ]

--Jason


Submitted by: Jason Wright <jason@oozoo.vnet.net>

        - src/backend/tcop/*
                - cosmetic changes to OPENLINK patches
        - src/backend/storage/*
                - more changes, mostly cosmetic
        - src/backend/ports/*
                - merge in patches for aix and i386_solaris

This is a patch to prevent an endless loop occuring in the Postgres backend
when a 'warning' error condition generates another warning error contition
in the handler code.

Submitted by: Chris Dunlop, <chris@onthe.net.au>