Re: dynamic shared memory

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

1. Do you think we should add information about pg_dynshmem file at link:
http://www.postgresql.org/docs/devel/static/storage-file-layout.html
It contains information about all files/folders in data directory

2.
+/*
+ * Forget that a temporary file is owned by a ResourceOwner
+ */
+void
+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