Gregory Stark <stark@enterprisedb.com> writes:
> "Tom Lane" <tgl@sss.pgh.pa.us> writes:
>> 4. Keep spawning a child, but mark it in the BackendList as known
>> doomed, and don't count such children when deciding if it's OK to
>> terminate. The problem with this idea is that such children will
>> still be connected to shared memory, and we really don't want to
>> terminate the postmaster before all connections to shmem are gone.
>> (This objection also applies to #1, now that I think about it.)
>>
>> I'm sort of leaning to solution #3, but I wondered if anyone had
>> a different opinion or a better idea.
> A variant on option 4 would be to stop accepting new connections once there
> are only known-doomed clients left. Ie, behave as if we're shut down already
> but not actually exit until all the known-doomed clients drain out.
> I think I agree that option 3 sounds simpler though.
After further thought, option 3 is not as nice as it looks. The
postmaster hasn't read the client's connection request message yet and
therefore doesn't know which protocol version it wants. We deal with
this in the fork-failure case by always sending a V2-protocol error
message (which newer clients are still expected to be able to handle).
However, that's not very nice, because there's no way to include a
SQLSTATE, and so client software wouldn't know *why* it got a failure,
unless it wants to try to recognize the possibly-localized message text
(ick). So doing this for startup/shutdown cases would be a noticeable
step backwards in client friendliness.
I'm tempted to stop accepting connections once we start the shutdown
checkpoint (ie, tell the bgwriter to shut down). This would at least
limit the width of the window in which incoming connections get ignored.
We could also close the sockets at that point, so that clients get an
immediate failure instead of hanging for awhile --- then it will look
to them like the postmaster is already gone.
Thoughts, better ideas?
regards, tom lane
