Re: shmem_seq may be a bad idea - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: shmem_seq may be a bad idea
Date
Msg-id Pine.GSO.4.02A.10005021037050.13753-100000@Iller.DoCS.UU.SE
Whole thread Raw
In response to Re: shmem_seq may be a bad idea  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: shmem_seq may be a bad idea  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden



pgsql-hackers by date:

Previous
From: Peter Mount
Date:
Subject: RE: Request for 7.0 JDBC status
Next
From: SAKAIDA
Date:
Subject: Re: psql \l error