Re: [HACKERS] POSIX shared memory support - Mailing list pgsql-patches

Yes, that is understandable. I'm not sure that there is a robust
portable solution that doesn't involve a major rearchitecture. I'm not
sure that would be worth the risk given the reward.

Thanks,
Chris

On Apr 2, 2008, at 8:50 AM, Bruce Momjian wrote:
>
> The original patch author:
>
>        Chris Marcellino <cmarcellino@apple.com>
>
> was not CC'ed as part of this email thread.  That was a mistake.
> Chris,
> the email thread discussing your patch is here:
>
>       http://archives.postgresql.org/pgsql-hackers/2008-03/
> msg01262.php
>
> Please read the discussion --- the bottom line is that there isn't
> much
> support for the patch.  Magnus was able to do the POSIX usage without
> relying on shared memory, but I just talked to him via IM and he
> said it
> used a Win32-specific feature that isn't portable to Unix.
>
> I am holding this patch for the next commit fest in hopes you can
> adjust
> it, but if not the patch will be rejected at that time.
>
> ---------------------------------------------------------------------------
>
> Stephen Frost wrote:
> -- Start of PGP signed section.
>> Chris, et al,
>>
>> (commit-fest consensus discussion)
>> * Chris Marcellino wrote:
>>> In case you haven't had enough, here is another version of the code
>>> to make Postgres use POSIX shared memory. Along with the issues that
>>> have already been addressed, this version ensures that orphaned
>>> backends are not in the database when restarting Postgres by using a
>>> single 1 byte SysV segment to see who is attached to the segment
>>> using shmctl/IPC_STAT/nattach.
>>
>> This really feels like a deal-breaker to me.  My first reaction to
>> this
>> patch, honestly, is that it's being justified for all the wrong
>> reasons.
>> Changing to POSIX shm seems like a reasonable goal in general,
>> provided
>> it can do what we need, but doing it to work around silly defaults
>> doesn't really work for me.  If the real issue you have is with the
>> SysV
>> limits then I'd suggest you bring that up with the kernel/
>> distribution
>> folks to get them to use something more sane.
>>
>> Looking around a bit, it looks like it's already being addressed in
>> some
>> places, for example Solaris 10 apparently uses 1/4th of memory, while
>> Centos 5 uses 4GB.  Suse also uses a larger default, from what I
>> understand.  Supporting this effort to get it raised on various
>> platforms and distributions seems like a much better approach.
>>
>> Additionally, it strikes me that there *is* a limit on POSIX shared
>> memory too, generally half of ram on the systems I've looked at, but
>> there's no guarentee that'll always be the default or that half of
>> ram
>> will always be enough for us.  So, even with this change, the problem
>> isn't completely 'solved'.
>>
>> Finding a way for POSIX shm to do what we need, including Tom's
>> concerns, without depending on SvsV shm as a crutch work around,
>> would
>> make this change much more reasonable and could be justified as
>> moving
>> to a well defined POSIX standard, and means we may be able to support
>> platforms which either are new and don't implement SysV but just
>> POSIX,
>> or cases where SysV is being actively depreceated.  Neither of
>> which is
>> possible if we're stuck with using it in some cases.
>>
>>     Thanks,
>>
>>         Stephen
> -- End of PGP section, PGP failed!
>
> --
>  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
>  EnterpriseDB                             http://enterprisedb.com
>
>  + If your life is a hard drive, Christ can be your backup. +