From: Tom Lane <tgl@sss.pgh.pa.us>
To: Noah Misch <noah@leadboat.com>
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: Unexpected "shared memory block is still in use"
Date: Fri, 10 May 2019 16:46:40 -0400
Message-ID: <16908.1557521200@sss.pgh.pa.us> (raw)
In-Reply-To: <25485.1557500141@sss.pgh.pa.us>
References: <22224.1557340366@sss.pgh.pa.us>
<20190509055414.GB1066859@rfd.leadboat.com>
<2663.1557409654@sss.pgh.pa.us>
<2226.1557439179@sss.pgh.pa.us>
<17642.1557442078@sss.pgh.pa.us>
<20190510072213.GA1098093@rfd.leadboat.com>
<25485.1557500141@sss.pgh.pa.us>
I wrote:
> Will go fix/backpatch in a minute.
Done now, but while thinking more about the issue, I had an idea: why is
it that we base the shmem key on the postmaster's port number, and not
on the data directory's inode number? Using the port number not only
increases the risk of collisions (though admittedly only in testing
situations), but it *decreases* our ability to detect real conflicts.
Consider case where DBA wants to change the installation's port number,
and he edits postgresql.conf, but then uses "kill -9 && rm postmaster.pid"
rather than some saner way of stopping the old postmaster. When he
starts the new one, it won't detect any remaining children of the old
postmaster because it'll be looking in the wrong range of shmem keys.
It seems like something tied to the data directory's identity would
be much more trustworthy.
I think the reason for doing it this way originally was to allow
one to identify which shmem segment is which in "ipcs -m" output.
But that was back when having to clean up shmem segments manually
was still a common task. It's been a long time since I can remember
needing to figure out which was which.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, noah@leadboat.com, pgsql-hackers@lists.postgresql.org
Subject: Re: Unexpected "shared memory block is still in use"
In-Reply-To: <16908.1557521200@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox