Re: GIN fast insert database hang

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: GIN fast insert database hang
Date: 2009-02-12 04:14:17
Message-ID: 603c8f070902112014v315b0dcam3542570ca361caac@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> I did this four times, sometimes with the variant of adding "set
> enable_bitmapscan to false;" before the explain analyze. In three
> cases the database recovered succesfully after the immediate shutdown;
> in the other case, it crapped out much as described in my original
> email.

Sorry to keep replying to myself, but I've figured that autovacuum is
not required to trigger this bug. In fact, I can reliably trigger it
much more quickly just by starting two concurrent copies of:

psql -c "insert into foo (x) select array[(random() * 100)::int,
(random() * 90)::int, (random()*80)::int] from
generate_series(1,100000);"

This freezes the whole system even with autovacuum = off in
postgresql.conf. As before, the backends wait on a semop() call.

I was able to reproduce the recovery failure this way once as well,
but that part of the problem seems to be much more erratic. Most of
the time after an immediate shutdown, pg_ctl start triggers recovery
followed by normal startup.

...Robert

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-02-12 04:40:29 Re: advance local xmin more aggressively
Previous Message Robert Haas 2009-02-12 03:33:53 Re: GIN fast insert database hang