On Fri, Jul 25, 2014 at 3:25 PM, Noah Misch <n...@leadboat.com> wrote:
> On a Windows or other EXEC_BACKEND build, the following eventually gets
> failures because all, or all but one, max_connections slot is consumed:
>
>   for run in `seq 1 100`; do make -C contrib/test_shm_mq installcheck; done
>
> When I use max_connections=40, it fails on the sixth iteration.  Only the six
> basic processes are actually running at that time.

The tests start 7 workers each time, so that makes sense: 7 * 5 < 40
but 7 * 6 > 40.  What I'm not sure is why they are leaking connection
slots, and why they're only doing it in EXEC_BACKEND mode.  A quick
code audit didn't uncover any obvious explanation, so I'll try to
reproduce and debug.

-- 
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

Reply via email to