On Wed, Oct 9, 2013 at 1:10 AM, Robert Haas <robertmh...@gmail.com> wrote:
> 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.

1. Do you think we should add information about pg_dynshmem file at link:
It contains information about all files/folders in data directory

+ * Forget that a temporary file is owned by a ResourceOwner
+ */
+ResourceOwnerForgetDSM(ResourceOwner owner, dsm_segment *seg)

Above function description should use 'dynamic shmem segment' rather
than temporary file.
"Forget that a dynamic shmem segment is owned by a ResourceOwner"

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to