Re: [GENERAL] startup process stuck in recovery
От | Tom Lane |
---|---|
Тема | Re: [GENERAL] startup process stuck in recovery |
Дата | |
Msg-id | 13728.1507595432@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [GENERAL] startup process stuck in recovery (Christophe Pettus <xof@thebuild.com>) |
Ответы |
Re: [GENERAL] startup process stuck in recovery
Re: [GENERAL] startup process stuck in recovery Re: [GENERAL] startup process stuck in recovery |
Список | pgsql-general |
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
В списке pgsql-general по дате отправления: