Michael J Davis <michael.j.davis@tvguide.com> writes:
> On the other hand, I expected others to suggest the techniques they use for
> debugging issues.
Well, the attach-to-a-running-backend procedure has always sufficed for
my purposes in backend debugging. (Some other people like to just start
a backend directly from gdb, but of course that's not going to shed much
light on connection failures.)
If you are having an authorization problem, it's not likely the backend
per se that's at fault --- connection authorization is done in the
postmaster before forking a subprocess, so you should be able to step
through the postmaster's checks just with gdb on the postmaster.
Actually, it'd be best to start with a debugger attached to the frontend
and see exactly what series of messages go back and forth. That would
at least give you an idea of what phase is failing. I have no idea how
to do that in a Windows/Access97 environment, but it's easy enough if
you are using psql or some other Unix frontend. (Read the "protocol"
chapter in the developer's guide to know what's supposed to happen,
then set breakpoints in connectDB() in fe-connect.c.)
It might be that just seeing what error message comes back from the
server will tell you what you need to know --- it looked to me like
Access was unhelpfully providing its own generic message instead of
quoting what the backend or postmaster had to say. (Note: I installed
more verbose connection-rejection messages just last week, so make sure
you have up to date sources.)
BTW, on at least some platforms, the most recent versions of gdb are
capable of dealing with forked subprocesses intelligently, so that's
also a possible answer if you are chasing a problem that occurs
immediately after the fork.
regards, tom lane
