From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
To: 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, 16 Aug 2019 15:09:57 +0200
Message-ID: <8cd56b77-dfd9-cfbe-cad2-663939b5f510@2ndquadrant.com> (raw)
In-Reply-To: <29530.1565738526@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>
<16908.1557521200@sss.pgh.pa.us>
<20190511190715.GA1124997@rfd.leadboat.com>
<29530.1565738526@sss.pgh.pa.us>
On 2019-08-14 01:22, Tom Lane wrote:
> Attached is a draft patch to change both shmem and sema key selection
> to be based on data directory inode rather than port.
>
> I considered using "st_ino ^ st_dev", or some such, but decided that
> that would largely just make it harder to manually correlate IPC
> keys with running postmasters. It's generally easy to find out the
> data directory inode number with "ls", but the extra work to find out
> and XOR in the device number is not so easy, and it's not clear what
> it'd buy us in typical scenarios.
For the POSIX APIs where the numbers are just converted to a string, why
not use both -- or forget about the inodes and use the actual data
directory string.
For the SYSV APIs, the scenario that came to my mind is if someone
starts a bunch of servers each on their own mount, it could happen that
the inodes of the data directories are very similar.
There is also the issue that AFAICT the key_t in the SYSV APIs is always
32-bit whereas inodes are 64-bit. Probably not a big deal, but it might
prevent an exact one-to-one mapping.
Of course, ftok() is also available here as an existing solution.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
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: peter.eisentraut@2ndquadrant.com, 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: <8cd56b77-dfd9-cfbe-cad2-663939b5f510@2ndquadrant.com>
* 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