Re: dynamic shared memory - Mailing list pgsql-hackers

From Robert Haas
Subject Re: dynamic shared memory
Date
Msg-id CA+TgmoZCRf0=DimouDt5jqc40aqX=N6L7jqL66O2QJ5oWS5ppQ@mail.gmail.com
Whole thread Raw
In response to Re: dynamic shared memory  (Jim Nasby <jim@nasby.net>)
Responses Re: dynamic shared memory
List pgsql-hackers
On Fri, Sep 6, 2013 at 3:40 PM, Jim Nasby <jim@nasby.net> wrote:
> The specific scenario I'm worried about is something like a PANIC in the
> middle of the snprintf call in dsm_write_state_file(). That would leave that
> file in a completely unknown state so who knows what would then happen on
> restart. ISTM that writing a temp file and then doing a filesystem mv would
> eliminate that issue.

Doing an atomic rename would eliminate the possibility of seeing a
partially written file, but a partially written file is mostly
harmless: we'll interpret whatever bytes we see as as integer and try
to use that as a DSM key.  Then we'll just see that no such shared
memory key exists (probably) or that we don't own it (probably) or
that it doesn't look like a valid control segment (probably) and
ignore it.

If someone does a kill -9 the postmaster in the middle of write()
creating a partially written file, and the partially written file
happens to identify another shared memory segment owned by the same
user ID with the correct magic number and header contents to be
interpreted as a control segment, then we will indeed erroneously blow
away that purported control segment and all other segments to which it
points.  I suppose we can stick in a rename() there just to completely
rule out that scenario, but it's pretty bloody unlikely anyway.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Strange hanging bug in a simple milter
Next
From: Robert Haas
Date:
Subject: Re: [RFC] overflow checks optimized away