Re: [RFC] Should we fix postmaster to avoid slow shutdown?

From: "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>
To: 'Ashutosh Bapat' <ashutosh(dot)bapat(at)enterprisedb(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [RFC] Should we fix postmaster to avoid slow shutdown?
Date: 2016-11-07 04:44:58
Message-ID: 0A3221C70F24FB45833433255569204D1F63BF1C@G01JPEXMBYT05
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

From: pgsql-hackers-owner(at)postgresql(dot)org
> [mailto:pgsql-hackers-owner(at)postgresql(dot)org] On Behalf Of Ashutosh Bapat
> I am not sure if following condition is a good idea in ServerLoop()
> 1650 if (pmState == PM_WAIT_DEAD_END || ClosedSockets)
>
> There are no sockets to listen on, so select in the else condition is going
> to sleep for timeout determined based on the sequence expected.
> Just before we close sockets in pmdie() it sets AbortStartTime, which
> determines the timeout for the sleep here. So, it doesn't make sense to
> ignore it. Instead may be we should change the default 60s sleep to 100ms
> sleep in DetermineSleepTime().

That sounds better. I modified cleaned ServerLoop() by pushing the existing 100ms logic into DetermineSleepTime().

> While the postmaster is terminating children, a new connection request may
> arrive. We should probably close listening sockets before terminating
> children in pmdie().

I moved ClosePostmasterSocket() call before terminating children in the immediate shutdown case. I didn't change the behavior of smart and fast shutdown modes, because they may take a long time to complete due to checkpointing etc. Users will want to know what's happening during shutdown or after pg_ctl stop times out, by getting the message "FATAL: the database system is shutting down" when they try to connect to the database. The immediate shutdown or crash should better be as fast as possible.

> Otherwise this patch looks good to me. It applies and compiles cleanly.
> make check-world doesn't show any failures.

Thank you for reviewing and testing. The revised patch is attached.

Regards
Takayuki Tsunakawa

Attachment Content-Type Size
02_close_listen_ports_early_v2.patch application/octet-stream 4.5 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tsunakawa, Takayuki 2016-11-07 05:16:03 Re: Remove the comment on the countereffectiveness of large shared_buffers on Windows
Previous Message Pavel Stehule 2016-11-07 04:43:22 Re: Let's get rid of SPI_push/SPI_pop