From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | Christophe Pettus <xof(at)thebuild(dot)com>, Postgresql General <pgsql-general(at)postgresql(dot)org>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Subject: | Re: startup process stuck in recovery |
Date: | 2017-10-11 14:00:12 |
Message-ID: | 5392.1507730412@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> On 11 October 2017 at 08:09, Christophe Pettus <xof(at)thebuild(dot)com> wrote:
>> While it's certainly true that this was an extreme case, it was a real-life production situation. The concern here is that in the actual production situation, the only symptom was that the startup process just stopped. There were no log messages or any other indication of what was going wrong.
> Which indicates it was making progress, just slowly.
> Tom says "This is pretty easy to diagnose though
> because it spews "out of shared memory" WARNING messages to the
> postmaster log at an astonishing rate"
> These don't seem to match.
Yeah. I'm still suspicious that Christophe saw some other misbehavior
than the one I found. We know his server was dealing with < 10K locks,
which doesn't seem like enough to cause any obvious problem from a mere
O(N^2) behavior.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2017-10-11 14:11:23 | Re: BUG #14850: Implement optinal additinal parameter for 'justify' date/time function |
Previous Message | Melvin Davidson | 2017-10-11 13:54:41 | Re: Determine size of table before it's committed? |