From: | Christophe Pettus <xof(at)thebuild(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Cc: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: startup process stuck in recovery |
Date: | 2017-10-10 18:37:15 |
Message-ID: | A168D954-3ABB-4676-A01A-5CD17A607E46@thebuild.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> On Oct 10, 2017, at 08:05, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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_zero THEN
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 iterations in the first to 20000.
--
-- Christophe Pettus
xof(at)thebuild(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Nico Williams | 2017-10-10 19:41:58 | Re: Equivalence Classes when using IN |
Previous Message | Scott Marlowe | 2017-10-10 16:05:38 | Re: Can master and slave on different PG versions? |