Re: shmem_seq may be a bad idea

From: Peter Eisentraut <e99re41(at)DoCS(dot)UU(dot)SE>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org, Michael Blakeley <mike(at)blakeley(dot)com>
Subject: Re: shmem_seq may be a bad idea
Date: 2000-05-02 08:46:53
Message-ID: Pine.GSO.4.02A.10005021037050.13753-100000@Iller.DoCS.UU.SE
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 1 May 2000, Tom Lane wrote:

> > Why not use IPC_EXCL to ensure you're getting a freshly baked shmem
> > segment rather than a recycled one?
>
> Hmm, that might work --- we'd need to add some logic to try to delete
> a conflicting segment and/or move on to another key if we can't.

How about you just pick a key (preferably using a standard method such as
ftok, but the current is fine as well if you like the traceability of keys
to servers) and if it's already used then increase it by one, try again.
For efficiency you could keep the last key that worked in a global and
start retrying from there. No need to try any fancy sequence number that
wrap after 10 times anyway and thus don't help in general.

A while ago while thinking about a way to make ipcclean better I thunk
that perhaps the postmaster should write the keys of the segments it gets
to a flat-text file. If it somehow crashes and loses track of what it
allocated before it can use that information to clean up. Not sure how
often that would take effect but it's very socially friendly.

--
Peter Eisentraut Sernanders väg 10:115
peter_e(at)gmx(dot)net 75262 Uppsala
http://yi.org/peter-e/ Sweden

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2000-05-02 08:50:36 Re: When malloc returns zero ...
Previous Message Peter Eisentraut 2000-05-02 08:34:17 RE: psql \l error