bhargav kamineni <bhargavpostgres@xxxxxxxxx> writes: >> What was the database doing just before the FATAL line? > Postgres was rejecting a bunch of connections from a user who is having a > connection limit set. that was the the FATAL error that i could see in log > file. > FATAL,53300,"too many connections for role ""user_app""" So ... how many is "a bunch"? Looking at the code, it seems like it'd be possible for a sufficiently aggressive spawner of incoming connections to reach the MaxLivePostmasterChildren limit. While the postmaster would correctly reject additional connection attempts after that, what it would not do is ensure that any child slots are left for new parallel worker processes. So we could hypothesize that the error you're seeing in the log is from failure to spawn a parallel worker process, due to being out of child slots. However, given that max_connections = 500, MaxLivePostmasterChildren() would be 1000-plus. This would mean that reaching this condition would require *at least* 500 concurrent connection-attempts-that-haven't-yet- been-rejected, maybe well more than that if you didn't have close to 500 legitimately open sessions. That seems like a lot, enough to suggest that you've got some pretty serious bug in your client-side logic. Anyway, I think it's clearly a bug that canAcceptConnections() thinks the number of acceptable connections is identical to the number of allowed child processes; it needs to be less, by the number of background processes we want to support. But it seems like a darn hard-to-hit bug, so I'm not quite sure that that explains your observation. regards, tom lane
