Re: shared memory message queues

On Tue, Jan 14, 2014 at 12:43 PM, Thom Brown <thom(at)linux(dot)com> wrote:
> postgres=# SELECT test_shm_mq(32768, (select
> string_agg(chr(32+(random()*96)::int), '') from generate_series(1,3)),
> 1, 10);
> ERROR: could not register background process
> HINT: You may need to increase max_worker_processes.
> STATEMENT: SELECT test_shm_mq(32768, (select
> string_agg(chr(32+(random()*96)::int), '') from generate_series(1,3)),
> 1, 10);
> LOG: registering background worker "test_shm_mq"
> LOG: starting background worker process "test_shm_mq"
> ERROR: could not register background process
> HINT: You may need to increase max_worker_processes.
> ERROR: unable to map dynamic shared memory segment
> LOG: worker process: test_shm_mq (PID 21939) exited with exit code 1
> LOG: unregistering background worker "test_shm_mq"
>
> What's going on here? This occurs when starting Postgres and run as
> the first statement.

Well, you requested 10 processes, but the default value of
max_worker_processes is 8. So, as the hint says, you may need to
increase max_worker_processes. Alternatively, you can decrease the
number of processes in the ring.

> I also noticed that everything exits with exit code 1:
>
> postgres=# SELECT test_shm_mq(32768, (select
> string_agg(chr(32+(random()*96)::int), '') from
> generate_series(1,400)), 10000, 1);
> LOG: registering background worker "test_shm_mq"
> LOG: starting background worker process "test_shm_mq"
> test_shm_mq
> -------------
>
> (1 row)
>
> LOG: worker process: test_shm_mq (PID 22041) exited with exit code 1
> LOG: unregistering background worker "test_shm_mq"

This is (perhaps unfortunately) required by the background-worker API.
When a process exits with code 0, it's immediately restarted
regardless of the restart-time setting. To get the system to respect
the restart time (in this case, "never") you have to make it exit with
code 1. It's been like this since the beginning, and I wasn't in a
hurry to change it even though it seems odd to me. Perhaps we should
revisit that decision.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company