Re: BUG #7885: postmaster panic on startup does not release shared memory

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: david(dot)thomas(at)enterprisedb(dot)com, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #7885: postmaster panic on startup does not release shared memory
Date: 2013-02-15 22:02:46
Message-ID: 18017.1360965766@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> When we panic, we PANIC, meaning we don't jump around looking for
> cleanup stuff, which might make things worse.

I think also there was some thought that we should intentionally leave
the shmem segment around for debugging purposes.

In any case, I believe the behavior complained of here is specific to
--single mode, which is surely not a production scenario, thus even
less reason to be concerned about it. (If a postmaster child panics,
the postmaster will still shut down normally and thus release the
shmem segment.)

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Dave Rolsky 2013-02-15 22:06:12 Re: BUG #7873: pg_restore --clean tries to drop tables that don't exist
Previous Message Bruce Momjian 2013-02-15 21:42:17 Re: BUG #7886: date_trunc(date) returning timestamptz instead of timestamp