How to disable Postgres from listening on IPv6?

I am trying to disable Postgres from listening on IPv6 because of a bunch of strange trace files that are constantly being written to syslog.

I'd prefer not to disable IPv6 in the OS itself, so after seeing mention of the trace messages, and finding the blog post Disable IPv6 Postgres and PGBouncer, I have followed step 2 and updated postgresql.conf (changing "*" to "0.0.0.0"):

# grep listen postgresql.conf
listen_addresses = '0.0.0.0'


I also found this entry in pg_hba.conf and commented it out:

# IPv6 local connections:
#host all all ::1/128 trust


I restarted Postgres. netstat seems to show that it's not listening on IPv6 any more:

# netstat -ntl | grep 5432
tcp 0 0 0.0.0.0:5432 0.0.0.0:* LISTEN


It seems that lsof has a different idea:

# lsof -i6 | grep postgres
postmaste 37921 postgres 8u IPv6 39125550 0t0 UDP
localhost:38892->localhost:38892
postmaste 37944 postgres 8u IPv6 39125550 0t0 UDP
localhost:38892->localhost:38892
postmaste 37945 postgres 8u IPv6 39125550 0t0 UDP
localhost:38892->localhost:38892



Could this be a bug? Or am I missing something obvious here?

System is:

Oracle Linux 6.9

Kernel 3.8.13-118.20.2.el6uek.x86_64

PostgreSQL 9.3.21

Trace file from syslog:

`Mar 9 13:36:35 atlassiandb100 kernel: ------------[ cut here ]------------
Mar 9 13:36:35 atlassiandb100 kernel: WARNING: at net/core/dst.c:285 dst_release+0x79/0x80()
Mar 9 13:36:35 atlassiandb100 kernel: Hardware name: PowerEdge R630
Mar 9 13:36:35 atlassiandb100 kernel: Modules linked in: ipmi_si dell_rbu nfsv3 nfs_acl nfsv4 auth_rpcgss nfs fscache lockd sunrpc 8021q garp stp llc bonding ipv6 ext3 jbd ext2 dm_queue_length dm_multipath dcdbas shpchp sg bnx2x ptp pps_core libcrc32c mdio coretemp hwmon kvm_intel kvm microcode pcspkr ipmi_devintf ipmi_msghandler ext4 jbd2 mbcache sd_mod crc_t10dif ghash_clmulni_intel crc32c_intel aesni

Thanks for the suggestions everyone. It hadn't clicked in my brain that the trace messages were caused by UDP communications. That led me to this blog post. It's not exactly my issue, but it led me ultimately to the solution:


PostgreSQL uses the POSIX function getaddrinfo(3) to resolve
localhost.

Testing the getaddrinfo function proved that it was returning ::1 before it was returning 127.0.0.1. I ended up commenting out the IPv6 line in /etc/hosts and re-starting Postgres. Voila! No more crazy trace messages in syslog.

StackExchange Database Administrators Q#199823, answer score: 7