Re: dynamic shared memory

On Thu, Sep 26, 2013 at 9:27 AM, Noah Misch <noah(at)leadboat(dot)com> wrote:
>> > "There's no data corruption problem if we proceed" - but there likely
>> > has been one leading to the current state.
>
> +1 for making this one a PANIC, though. With startup behind us, a valid dsm
> state file pointed us to a control segment with bogus contents. The
> conditional probability of shared memory corruption seems higher than that of
> a DBA editing the dsm state file of a running cluster to incorrectly name as
> the dsm control segment some other existing shared memory segment.

To respond specifically to this point... inability to open a file on
disk does not mean that shared memory is corrupted. Full stop.

A scenario I have seen a few times is that someone changes the
permissions on part or all of $PGDATA while the server is running. I
have only ever seen this happen on Windows. What typically happens
today - depending on the exact scenario - is that the checkpoints will
fail, but the server will remain up, sometimes even committing
transactions under synchronous_commit=off, even though it can't write
out its data. If you fix the permissions before shutting down the
server, you don't even lose any data. Making inability to read a file
into a PANIC condition will cause any such cluster to remain up only
as long as nobody tries to use dynamic shared memory, and then throw
up its guts. I don't think users will appreciate that.

I am tempted to commit the latest version of this patch as I have it.
I think there's a lot of bikeshedding left to be done here, but
there's no real reason why we can't change this subsequent to the
initial commit as the answers become more clear. Changing the error
levels used for particular messages, or rearranging the directory
structure, is quite trivial. But we can't do that as long as we have
N people with >=N opinions on what to do, and the way to get more
clarity there is to get the code out in front of a few more people and
see how things shake out.

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