Noah Misch-2 wrote
>> > I'm thinking to preserve postmaster.pid at immediate shutdown in all
>> released
>> > versions, but I'm less sure about back-patching a change to make
>> > PGSharedMemoryCreate() pickier. On the one hand, allowing startup to
>> proceed
>> > with backends still active in the same data directory is a corruption
>> hazard.
>>
>> The corruption risk, imv anyway, is sufficient to backpatch the change
>> and overrides the concerns around very fast shutdown/restarts.
>
> Making PGSharedMemoryCreate() pickier in all branches will greatly
> diminish
> the marginal value of preserving postmaster.pid, so I'm fine with dropping
> the
> postmaster.pid side of the proposal.
Its probably still worth a fresh look at the immediate shutdown process to
see whether the current location where postmaster.pid is removed is
acceptable. It may not be necessary to leave it in place always but:
1) if there is a section of shared memory that can only be reached/found if
one knows the pid, and
2) postmaster.pid is removed before that area is "secured from future
clobbering"
then there may be a risk that can still be mitigated by moving its removal
without having to go to the extreme.
David J.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Weaker-shmem-interlock-w-o-postmaster-pid-tp5770399p5770559.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.