On 9/14/18 8:43 AM, Jeremy Schneider wrote:
> Hi Chris - this is an interesting one that we do see from time to time;
> seems worth responding here as actually our best understanding right now
> is that this is something in community code, not AWS-specific.
>
>
> On 9/13/18 16:10, Adrian Klaver wrote:
>> The thing is, what you are doing ("(e.g. reboot, changing instance
>> size, etc.)") are instance operations not database operations. That
>> comes under AWS's purview.
>
> Correct, managing reboots and hardware reconfigurations would be the
> responsibility of AWS. However Chris' issue here is just that PostgreSQL
> itself took a long time to shut down. I'm not aware of anything
> RDS-specific with this.
The thing is I do not remember any posts to this list mentioning the
same problem on a platform outside RDS. A quick search seems to confirm
that.
Would it be possible to see the RDS shutdown script?
>
> I don't know about this specific incident, but I do know that the RDS
> team has seen cases where a backend gets into a state (like a system
> call) where it's not checking signals and thus doesn't receive or
> process the postmaster's request to quit. We've seen these processes
> delay shutdowns and also block recovery on streaming replicas.
The particulars of that state?
> FYI, yes there is a timeout on the RDS side. The basic workflow is to
> try to shutdown postgres the normal way, and if it hasn't cleanly shut
> down after a period of time then forcefully kill it.
>
>
>
> Hope this helps,
> Jeremy
>
>
--
Adrian Klaver
adrian.klaver@aklaver.com
