Re: Unexpected "shared memory block is still in use"

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Unexpected "shared memory block is still in use"
Date: 2019-05-10 20:46:40
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Nasby, Jim 2019-05-10 21:07:05 Re: Problems with pg_upgrade and extensions referencing catalog tables/views
Previous Message Tom Lane 2019-05-10 20:29:18 Re: REINDEX INDEX results in a crash for an index of pg_class since 9.6