Re: [GENERAL] startup process stuck in recovery - Mailing list pgsql-general

From Christophe Pettus
Subject Re: [GENERAL] startup process stuck in recovery
Date
Msg-id A168D954-3ABB-4676-A01A-5CD17A607E46@thebuild.com
Whole thread Raw
In response to Re: [GENERAL] startup process stuck in recovery  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [GENERAL] startup process stuck in recovery  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: [GENERAL] startup process stuck in recovery
Next
From: Nico Williams
Date:
Subject: Re: [GENERAL] Equivalence Classes when using IN