From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Christophe Pettus <xof(at)thebuild(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: startup process stuck in recovery |
Date: | 2017-10-09 20:26:46 |
Message-ID: | 2961.1507580806@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Christophe Pettus <xof(at)thebuild(dot)com> writes:
>> On Oct 9, 2017, at 13:01, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Is that number changing at all?
> Increasing:
> AccessExclusiveLock | 8810
Oh, that's really interesting. So it's not *just* releasing locks but
also acquiring them, which says that it is making progress of some sort.
My bet is that the source server did something that's provoking O(N^2)
behavior in the standby server's lock management. It's hard to say
exactly what, but I'm wondering about something like a plpgsql function
taking an AccessExclusiveLock inside a loop that repeatedly traps an
exception. Can you correlate where the standby is stuck with what
was happening on the source?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Christophe Pettus | 2017-10-09 21:01:06 | Re: startup process stuck in recovery |
Previous Message | Christophe Pettus | 2017-10-09 20:10:11 | Re: startup process stuck in recovery |