From: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)2ndquadrant(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Something fishy happening on frogmouth |
Date: | 2013-10-31 23:48:58 |
Message-ID: | 5272EC6A.2020004@vmware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 31.10.2013 16:43, Robert Haas wrote:
> Let me say this again: the dynamic shared memory code *does* clean up
> after itself. If you kill -9 the postmaster and all of its children,
> you'll orphan the main shared memory segment and any dynamic shared
> memory segments that exist. There is nothing we can do about that.
> When you restart the postmaster, both the main shared memory segment
> and any dynamic shared memory segments orphaned by the previous kill
> will be cleaned up. I spent a lot of time trying to make sure that
> the handling of dynamic shared memory segments is, in all cases, as
> parallel to the handling of the main shared memory segment as
> possible. There should be no cases where the main shared memory
> segment gets cleaned up and the dynamic shared memory segments do not.
1. initdb -D data1
2. initdb -D data2
3. postgres -D data1
4. killall -9 postgres
5. postgres -D data2
The system V shmem segment orphaned at step 4 will be cleaned up at step
5. The DSM segment will not.
BTW, 9.3 actually made the situation a lot better for the main memory
segment. You only leak the small interlock shmem segment, the large
mmap'd block does get automatically free'd when the last process using
it exits.
- Heikki
From | Date | Subject | |
---|---|---|---|
Next Message | Adrian Klaver | 2013-11-01 00:03:05 | Re: postgresql-9.3.1-1-windows-x64.exe does not install correctly for me |
Previous Message | Kevin Grittner | 2013-10-31 22:22:57 | Re: [BUGS] BUG #8542: Materialized View with another column_name does not work? |