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
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 |