The following bug has been logged online: Bug reference: 3902 Logged by: Peter Koczan Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3RC2 Operating system: Red Hat Enterprise Linux 5 Description: Segmentation faults using GSSAPI authentication Details:
Trying to connect via GSSAPI (with Kerberos 5 as the underlying mechanism) after the server has been under a very slight load results in an unusable but still running server. I was able to produce this problem by trying to connect to the database, run a few commands, disconnect, and trying to reconnect. I was also able to produce this when trying to connect via GSSAPI to a server when it was restoring a database (using local trust authentication). The syslog output shows many of these errors when trying to connect from one such server process: Jan 24 15:46:17 mitchell postgres[14663]: [1-1] LOG: could not load root certificate file "root.crt": No such file or directory Jan 24 15:46:17 mitchell postgres[14663]: [1-2] DETAIL: Will not verify client certificates. Jan 24 15:46:17 mitchell postgres[14663]: [2-1] LOG: database system is ready to accept connections Jan 24 16:16:18 mitchell postgres[14663]: [3-1] LOG: received SIGHUP, reloading configuration files Jan 24 16:18:31 mitchell postgres[14663]: [4-1] LOG: server process (PID 15004) was terminated by signal 11: Segmentation fault Jan 24 16:18:31 mitchell postgres[14663]: [5-1] LOG: terminating any other active server processes Jan 24 16:18:31 mitchell postgres[14663]: [6-1] LOG: all server processes terminated; reinitializing Jan 24 16:18:31 mitchell postgres[14663]: [7-1] LOG: database system is ready to accept connections Jan 24 16:48:49 mitchell postgres[14663]: [8-1] LOG: received smart shutdown request The client connection shows this: $ /s/postgresql-8.3-RC2/bin/psql -h mitchell -p 5434 psql: server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. Syslog for a connection shows this: Jan 24 16:16:59 mitchell postgres[15004]: [4-1] LOG: connection received: host=ator.cs.wisc.edu port=35608 Jan 24 16:16:59 mitchell postgres[15004]: [5-1] LOG: connection authorized: user=koczan database=postgres It is important to note that connecting via native Kerberos 5 does not cause this problem, nor does going via md5 or trust authentication. I compiled against Kerberos 5 - 1.6.2 ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match