On Mon, Apr 28, 2014 at 7:37 AM, Andres Freund <and...@2ndquadrant.com> wrote: >> Well, often that's still good enough. > > That may be true for 2-4k max_connections, but >65k? That won't even > *run*, not to speak of doing something, in most environments because of > the number of processes required. > > Even making only 20k connections will probably crash your computer.
I'm of two minds on this topic. On the one hand, "cat /proc/sys/kernel/pid_max" on a Linux system I just tested (3.2.6) returns 65536, so we'll run out of PID space before we run out of 64k backends. On the other hand, that value can easily be increased to a few million via, e.g., sysctl -w kernel.pid_max=4194303, and I imagine that as machines continue to get bigger there will be more and more people wanting to do things like that. I think the fact that making 20k connections might crash your computer is an artifact of other problems that we really ought to also fix (like per-backend memory utilization, and lock contention on various global data structures) rather than baking it into more places. In PostgreSQL 25.3, perhaps we'll be able to run distributed PostgreSQL clusters that can service a million simultaneous connections across dozens of physical machines. Then again, there might not be much left of our current buffer manager by that point, so maybe what we decide right now isn't that relevant. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers