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-10 00:30:32 |
Message-ID: | 13728.1507595432@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:
> The problem indeed appear to be a very large number of subtransactions, each one creating a temp table, inside a single transaction. It's made worse by one of those transactions finally getting replayed on the secondary, only to have another one come in right behind it...
Hmm, I tried to reproduce this and could not. I experimented with
various permutations of this:
create or replace function goslow(n int) returns void language plpgsql as
$$
begin
for i in 1..n loop
begin
execute 'create temp table myfoo' || i || '(f1 int)';
perform i/0;
exception when division_by_zero then null;
end;
end loop;
perform n/0;
end;
$$;
and did not see any untoward behavior, at least not till I got to enough
temp tables to overrun the master's shared lock table, and even then it
cleaned up fine. At no point was the standby process consuming anywhere
near as much CPU as the master's backend.
What am I missing to reproduce the problem?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2017-10-10 01:02:20 | Re: startup process stuck in recovery |
Previous Message | David Rowley | 2017-10-09 23:52:37 | Re: Equivalence Classes when using IN |