Re: backend hangs at immediate shutdown (Re: Back-branch update releases coming in a couple weeks)

From: "Robert Haas" <robertmhaas(at)gmail(dot)com>
> On Fri, Jun 21, 2013 at 10:02 PM, MauMau <maumau307(at)gmail(dot)com> wrote:
>> I'm comfortable with 5 seconds. We are talking about the interval
>> between
>> sending SIGQUIT to the children and then sending SIGKILL to them. In
>> most
>> situations, the backends should terminate immediately. However, as I
>> said a
>> few months ago, ereport() call in quickdie() can deadlock indefinitely.
>> This
>> is a PostgreSQL's bug.
>
> So let's fix that bug. Then we don't need this.

tHERE ARE TWO WAYS TO FIX THAT BUG. yOU ARE SUGGESTING 1 OF THE FOLLOWING
TWO METHODS, AREN'T YOU?

1. (rOBERT-SAN'S IDEA)
uPON RECEIPT OF IMMEDIATE SHUTDOWN REQUEST, POSTMASTER SENDS sigkill TO ITS
CHILDREN.

2. (tOM-SAN'S IDEA)
uPON RECEIPT OF IMMEDIATE SHUTDOWN REQUEST, POSTMASTER FIRST SENDS sigquit
TO ITS CHILDREN, WAIT A WHILE FOR THEM TO TERMINATE, THEN SENDS sigkill TO
THEM.

aT FIRST i PROPOSED 1. tHEN tOM SAN SUGGESTED 2 SO THAT THE SERVER IS AS
FRIENDLY TO THE CLIENTS AS NOW BY NOTIFYING THEM OF THE SERVER SHUTDOWN. i
WAS CONVINCED BY THAT IDEA AND CHOSE 2.

bASICALLY, i THINK BOTH IDEAS ARE RIGHT. tHEY CAN SOLVE THE ORIGINAL
PROBLEM.

hOWEVER, RE-CONSIDERING THE MEANING OF "IMMEDIATE" SHUTDOWN, i FEEL 1 IS A
BIT BETTER, BECAUSE TRYING TO DO SOMETHING IN QUICKDIE() OR SOMEWHERE DOES
NOT MATCH THE IDEA OF "IMMEDIATE". wE MAY NOT HAVE TO BE FRIENDLY TO THE
CLIENTS AT THE IMMEDIATE SHUTDOWN. tHE CODE GETS MUCH SIMPLER. iN
ADDITION, IT MAY BE BETTER THAT WE SIMILARLY SEND sigkill IN BACKEND CRASH
(fATALeRROR) CASE, ELIMINATE THE USE OF sigquit AND REMOVE QUICKDIE() AND
OTHER sigquit HANDLERS.

wHAT DO YOU THINK? hOW SHOULD WE MAKE CONSENSUS AND PROCEED?

rEGARDS
mAUmAU