Robert Haas <robertmh...@gmail.com> writes:
> On Fri, Mar 7, 2014 at 2:40 PM, Robert Haas <robertmh...@gmail.com> wrote:
>> Hmm. So the problematic sequence of events is where a postmaster
>> child forks, and then exits without exec-ing, perhaps because e.g.
>> exec fails?
> I've attempted a fix for this case. The attached patch makes
> test_shm_mq fork() a child process that calls on_exit_reset() and then
> exits. Without the fix I just pushed, this causes the tests to fail;
> with this fix, this does not cause the tests to fail.
> I'm not entirely sure that this is exactly right, but I think it's an
> improvement.
This looks generally sane to me, but I wonder whether you should also
teach PGSharedMemoryDetach() to physically detach from DSM segments
not just the main shmem seg. Or maybe better, adjust most of the
places that call on_exit_reset and then PGSharedMemoryDetach to also
make a detach-from-DSM call. It looks like both sysv_shmem.c and
win32_shmem.c have internal callers of PGSharedMemoryDetach, which
probably shouldn't affect DSM.
You could argue that that's unnecessary on the grounds that the postmaster
will never have any DSM segments attached, but I think it would be
good coding practice anyway. People who copy-and-paste those bits of
code into other places are not likely to think of adding DSM calls.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
