Re: Dynamic Shared Memory stuff

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Dynamic Shared Memory stuff
Date: 2014-04-08 15:45:34
Message-ID: CA+Tgmoa6idewE5oRVq0+zw33dhBBrsWsPx3ffxifFU+Ff-TjRQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Apr 4, 2014 at 10:01 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Wed, Jan 22, 2014 at 10:17 AM, Noah Misch <noah(at)leadboat(dot)com> wrote:
>> Yeah, abandoning the state file is looking attractive.
>
> Here's a draft patch getting rid of the state file. This should
> address concerns raised by Heikki and Fujii Masao and echoed by Tom
> that dynamic shared memory behaves differently than the main shared
> memory segment. The control segment ID is stored in the System V
> shared memory block, so we're guaranteed that when using either System
> V or POSIX shared memory we'll always latch onto the control segment
> that matches up with the main shared memory segment we latched on to.
> Cleanup for the file-mmap and Windows methods doesn't need to change,
> because the former always just means clearing out $PGDATA/pg_dynshmem,
> and the latter is done automatically by the operating system.
>
> Comments?

Apparently not. However, I'm fairly sure this is a step toward
addressing the complaints previously raised, even if there may be some
details people still want changed, so I've gone ahead and committed
it.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2014-04-08 15:48:06 Re: Doc typo in "9.28. Event Trigger Functions"
Previous Message Robert Haas 2014-04-08 15:37:31 Re: Fwd: Proposal: variant of regclass