| From: | Christophe Pettus <xof(at)thebuild(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-general(at)postgresql(dot)org |
| Subject: | Re: startup process stuck in recovery |
| Date: | 2017-10-09 21:24:00 |
| Message-ID: | C58F21EC-D926-4C49-903F-329773FAA77C@thebuild.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
> On Oct 9, 2017, at 13:26, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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?
Interestingly, the OIDs for the relations on which the locks on the secondary are held aren't present in pg_class, and they're clustered together. Could a large number of temporary table creations that are being undone by an abort cause this?
--
-- Christophe Pettus
xof(at)thebuild(dot)com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2017-10-09 21:29:38 | Re: startup process stuck in recovery |
| Previous Message | Christophe Pettus | 2017-10-09 21:01:06 | Re: startup process stuck in recovery |