Re: BUG #3902: Segmentation faults using GSSAPI authentication

> I think you misunderstand what is happening. The parent postmaster
> process is not restarting, because it did not crash. The crash is
> happening in a child process that is forked off by the postmaster to
> service a particular connection.

I see what you're saying, that it's one particular connection issue
causing these problems. I thought it was a postmaster issue since the
database went into recovery mode for a bit and *all* connections
attempted to reset.

> No, we want a stack trace from the crash. You could attach gdb to the
> child process after forking and before you provoke the crash; or arrange
> for a core dump file to be produced and gdb that.

I should be able to get that for you tomorrow, if we don't figure out
the issue sooner.

> I couldn't reproduce this at all on Fedora 8. I speculate that you've
> not told us enough about the configuration you're using. Given that the
> crash doesn't happen until after "connection authorized" is logged, it
> seems likely that the problem is not purely GSSAPI's fault but is an
> interaction with some other option that I happen not to be using.
> Please show your configure options and all non-default postgresql.conf
> settings.

postgresql.conf entries (uncommented ones):
listen_addresses = '*'
port = 5434
max_connections = 300
unix_socket_directory = '/tmp'
ssl = on
krb_server_keyfile = '/etc/v5srvtab.postgres'
work_mem = 10MB
shared_buffers = 250MB
max_fsm_pages = 250000
max_fsm_relations = 5000
default_statistics_target = 100
log_destination = 'syslog'
syslog_facility = 'LOCAL1'
log_checkpoints = on
log_connections = on
log_disconnections = on
log_duration = off
log_hostname = on
log_line_prefix = ''
datestyle = 'iso, mdy'
lc_messages = 'en_US.UTF-8'
lc_monetary = 'en_US.UTF-8'
lc_numeric = 'en_US.UTF-8'
lc_time = 'en_US.UTF-8'
default_text_search_config = 'pg_catalog.english'

And my configure/build options:
export LDFLAGS="-L/s/openssl-0.9.8e/lib -L/s/krb5-1.6.2/lib
-L/s/readline-5.2/lib -L/s/libxml2-2.6.30/lib
-Wl,-rpath,/s/openssl-0.9.8e/lib -Wl,-rpath,/s/krb5-1.6.2/lib
-Wl,-rpath,/s/readline-5.2/lib -Wl,-rpath,/s/libxml2-2.6.30/lib"
export CFLAGS="-I/s/openssl-0.9.8e/include -I/s/krb5-1.6.2/include
-I/s/readline-5.2/include -I/s/libxml2-2.6.30/include"
./configure --prefix=/s/postgresql-8.3-RC2/i386_rhel5 \
--with-includes=/s/openssl-0.9.8e/include:/s/krb5-1.6.2/include:/s/readline-5.2/include:/s/libxml2-2.6.30/include
\
--with-libraries=/s/openssl-0.9.8e/lib:/s/krb5-1.6.2/lib:/s/readline-5.2/lib:/s/libxml2-2.6.30/lib
\
--with-gssapi \
--with-krb5 \
--with-openssl \
--with-pam \
--with-libxml \
--with-perl \
--with-python

> BTW, I couldn't get GSSAPI to work at all without a fully-specified -h
> option; it kept trying to use the wrong Kerberos principal names.
> I wonder whether that is related --- how did you persuade it to do the
> above? Special sauce in krb5.conf maybe?

I'll check with our main kerberos admin to see if there's anything
weird in our krb5.conf. Is there anything in particular to look for?

However, I think the special sauce is in DNS. There's an unqualified
name in /etc/hosts that can resolve to the FQDN.

$ grep mitchell /etc/hosts
[IP address] mitchell.cs.wisc.edu mitchell