On Thu, Sep 26, 2013 at 9:27 AM, Noah Misch <n...@leadboat.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers