Re: [GENERAL] startup process stuck in recovery
От | Christophe Pettus |
---|---|
Тема | Re: [GENERAL] startup process stuck in recovery |
Дата | |
Msg-id | A168D954-3ABB-4676-A01A-5CD17A607E46@thebuild.com обсуждение исходный текст |
Ответ на | Re: [GENERAL] startup process stuck in recovery (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [GENERAL] startup process stuck in recovery
|
Список | pgsql-general |
> On Oct 10, 2017, at 08:05, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > You're right, I was testing on HEAD, so that patch might've obscured > the problem. But the code looks like it could still be O(N^2) in > some cases. Will look again later. I was able to reproduce this on 9.5.9 with the following: DO $$ DECLARE i int := 1; BEGIN FOR i IN 1..12000 LOOP BEGIN PERFORM f(); i := i / 0; EXCEPTION WHEN division_by_zeroTHEN END; END LOOP; END; $$ language plpgsql; where f() is: CREATE OR REPLACE FUNCTION f() RETURNS VOID AS $$ BEGIN CREATE TEMPORARY TABLE test_table ON COMMIT DROP AS SELECT i FROM generate_series(1, 100) i; END: $$ language plpgsql; A couple of observations: -- In this version, I couldn't do a select * from pg_locks() on the secondary without getting an out-of-shared-memory error. -- If I increased max_locks_per_transaction to 15000, the problem didn't occur, even if I bumped up the number of iterationsin the first to 20000. -- -- Christophe Pettus xof@thebuild.com -- 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 по дате отправления: