Christophe Pettus <xof@thebuild.com> writes:
> The problem indeed appear to be a very large number of subtransactions, each one creating a temp table, inside a
singletransaction. It's made worse by one of those transactions finally getting replayed on the secondary, only to
haveanother 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_zerothen 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
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
