Re: DSM robustness failure (was Re: Peripatus/failures)
| От | Thomas Munro |
|---|---|
| Тема | Re: DSM robustness failure (was Re: Peripatus/failures) |
| Дата | |
| Msg-id | CAEepm=0Oz7m_1EV8Bhc80mKn6XCXeFkRsVuFrXdFvjRcKBXR+A@mail.gmail.com обсуждение исходный текст |
| Ответ на | DSM robustness failure (was Re: Peripatus/failures) (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: DSM robustness failure (was Re: Peripatus/failures)
|
| Список | pgsql-hackers |
On Thu, Oct 18, 2018 at 9:00 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 2018-10-17 13:43:24.235 CDT [46467:6] LOG: dynamic shared memory control segment is corrupt
> TRAP: FailedAssertion("!(dsm_control_mapped_size == 0)", File: "dsm.c", Line: 181)
>
> It looks to me like what's happening is
>
> (1) crashing process corrupts the DSM control segment somehow.
I wonder how. Apparently mapped size was tiny (least likely
explanation), control->magic was wrong, or control->maxitems and
control->nitems were inconsistent with each other or the mapped size.
> (2) dsm_postmaster_shutdown notices that, bleats to the log, and
> figures its job is done.
Right, that seems to be the main problem.
> (3) dsm_postmaster_startup crashes on Assert because
> dsm_control_mapped_size isn't 0, because the old seg is still mapped.
Right.
> I would argue that both dsm_postmaster_shutdown and dsm_postmaster_startup
> are broken here; the former because it makes no attempt to unmap
> the old control segment (which it oughta be able to do no matter how badly
> broken the contents are), and the latter because it should not let
> garbage old state prevent it from establishing a valid new segment.
Looking.
> BTW, the header comment on dsm_postmaster_startup is a lie, which
> is probably not unrelated to its failure to consider this situation.
Agreed.
--
Thomas Munro
http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: