Postgresql – postgres 9.1: both md5 and ident on the same connection type

I think you see a false dichotomy that does not exist.

It can be useful to have connection pooling in place even if you expect a 1:1 mapping of clients to back-ends. If your connections are long-lived, you won't benefit from reducing backend setup/teardown overhead, as it's small and amortized across a long period. A pool like PgBouncer may remain useful for other reasons:

• Block until a connection is available rather than return an immediate max_connections exceeded error;
• You can switch the pool target server if you fail-over to a standby without having to reconfigure applications;
• You can limit application database workers to lower than max_connections, so you can still make reporting and maintenance connections as a non-superuser.

Additionally, if suitable for your application you can use transaction-level pooling to greatly increase the number of clients that can be served by your server.

I would not try to keep a strict 1:1 mapping from Apache workers to PostgreSQL workers, personally. If you've got (say) 16 cores and good I/O on your PostgreSQL box you might want something like 16-20 active PostgreSQL workers for optimal performance. You're almost certain to want more Apache workers than that, since they'll be kept busy by things like:

• persistent HTTP connections from idle clients;
• Unresponsive or very slow clients;
• Intentional DoS connections;
• Network interruptions between client and server; etc

If possible, consider a transaction-pooling design with short-lived transactions instead.

Maybe it is not the finest Solution / Answer to my question, but at least it will point anybody (facing the said challenge I had in my original question)

To disable listening on TCP/IP network I used this command line option when starting the server application:

postgres [other arguments] -c listen_addresses=''

Addition: The remaining open udp 127.0.0.1:38860 connection is supposedly linked to the purpose of the the statistics collector subprocess as suggested on postgresql.org