Re: shmem_seq may be a bad idea

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
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-01 19:49:47
Message-ID: Pine.LNX.4.21.0005011237120.389-100000@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane writes:

> When a postmaster initially starts up, it uses a key value of
> PortNumber * 1000. However, if it is forced to do a system-wide
> restart because of a backend crash, it generates a new key value
> different from the old one, namely PortNumber * 1000 + shmem_seq *
> 100, so that the old shared-memory segments are discarded and a new
> set is created.

Why not use IPC_EXCL to ensure you're getting a freshly baked shmem
segment rather than a recycled one?

> The intent of this logic is evidently to ensure that the old, failed
> backends can't somehow corrupt the new ones.

But what if someone runs another postmaster at port 5433, will it
eventually interfere? Or some totally different program? Trying to
generate distinct number to use for keys is only one part of the equation,
but you still have to check whether the number was distinct enough.

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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2000-05-01 19:50:14 Re: When malloc returns zero ...
Previous Message Tom Lane 2000-05-01 19:12:44 Re: RE: [PATCHES] relation filename patch