Attached is a patch that removes the use of the flat auth file during
client authentication, instead using regular access to the pg_auth
catalogs. As previously discussed, this implies pushing the
authentication work down to InitPostgres. I didn't yet do anything
about the idea of falling back to connecting to "postgres" when the
specified target DB doesn't exist, but other than that small change
I think it's about ready to go.
The main thing that turned out to be unexpectedly, um, "interesting" was
signal handling. What we have been doing during client authentication
is to point SIGTERM, SIGALRM, etc to the "authdie" handler, which just
does "proc_exit(1)" directly. This will *not* do once we've entered a
transaction --- in general you can't expect to just interrupt the
backend in a random place and start doing something different. I'm not
really sure it was safe even during authentication, but for sure it's
not safe during database access. The solution that's adopted here is to
use the regular backend SIGINT, SIGTERM, SIGQUIT, and SIGALRM signal
handling, and to turn on ImmediateInterruptOK while we are doing client
interactions during authentication, but not while we are doing database
accesses during authentication. It's a bit ugly because the signal
handlers have to be taught to do something different when
ClientAuthInProgress, but I don't see a better way.
Another interesting point is that for this to work, those signal
interrupts have to actually be enabled (doh) ... and up to now we have
been running InitPostgres with most signals disabled. I suspect that
this means some things are actively broken during InitPostgres's initial
transaction --- for example, if it happens to try to take a lock that
completes a deadlock cycle, the deadlock won't be detected because the
lock timeout SIGALRM interrupt will never occur. Another example is
that SI inval messaging isn't working during InitPostgres either.
The patch addresses this by moving up PostgresMain's
PG_SETMASK(&UnBlockSig); call to before InitPostgres. We might need to
back-patch that bit, though I'm hesitant to fool with such a thing in
back branches.
Thoughts, objections, better ideas?
regards, tom lane
