| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: on_exit_reset fails to clear DSM-related exit actions |
| Date: | 2014-03-10 14:26:23 |
| Message-ID: | CA+TgmoYfmMChD_csLcVwJs_yeBL3sPcxZguGLO=7+Jtb_YNWqA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Mar 7, 2014 at 2:40 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> The big picture here is that in the scenario being debated in the other
>> thread, exit() in a child process forked from a backend will execute that
>> backend's on_detach actions *even if the code had done on_exit_reset after
>> the fork*.
>
> 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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| Attachment | Content-Type | Size |
|---|---|---|
| forktest.patch | text/x-patch | 846 bytes |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2014-03-10 14:31:20 | Re: Performance Improvement by reducing WAL for Update Operation |
| Previous Message | Pavel Stehule | 2014-03-10 13:58:22 | pg_upgrade on high number tables database issues |