| From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
|---|---|
| To: | Christophe Pettus <xof(at)thebuild(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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 08:27:17 |
| Message-ID: | CANP8+jLQOv7pSifvTM6uf7Xe9hnKs4u5a1fv+xssctBCwOCn5g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On 11 October 2017 at 08:09, Christophe Pettus <xof(at)thebuild(dot)com> wrote:
>
>> On Oct 10, 2017, at 23:54, Simon Riggs <simon(at)2ndQuadrant(dot)com> wrote:
>>
>> The use case described seems incredibly
>> unreal and certainly amenable to being rewritten.
>
> 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.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | kes-kes | 2017-10-11 10:35:12 | BUG #14850: Implement optinal additinal parameter for 'justify' date/time function |
| Previous Message | Thomas Kellerer | 2017-10-11 07:41:58 | Why does increasing the precision of a numeric column rewrites the table? |