Re: pgbench unusable after crash during pgbench - Mailing list pgsql-hackers

From Robert Haas
Subject Re: pgbench unusable after crash during pgbench
Date
Msg-id CA+TgmobJDdwd6TiDeLKfuXP-brK8Hz-nvh1WaKm8mDCgQd662g@mail.gmail.com
Whole thread Raw
In response to pgbench unusable after crash during pgbench  (Thom Brown <thom@linux.com>)
Responses Re: pgbench unusable after crash during pgbench  (Thom Brown <thom@linux.com>)
List pgsql-hackers
On Thu, Nov 19, 2015 at 6:03 AM, Thom Brown <thom@linux.com> wrote:
> I'm using git master, and if I crash the database whilst it's running
> pgbench, then restart the database and try to run pgbench again, I
> can't:
>
> thom@swift:~/Development/postgresql$ pgbench -c 1 -j 1 -T 20 -S pgbench
> ...crash database...
> connection to database "pgbench" failed:
> could not connect to server: Connection refused
>     Is the server running locally and accepting
>     connections on Unix domain socket "/tmp/.s.PGSQL.5488"?
> thom@swift:~/Development/postgresql$ pg_ctl start
> pg_ctl: another server might be running; trying to start server anyway
> server starting
> thom@swift:~/Development/postgresql$ pgbench -c 1 -j 1 -T 20 -S pgbench
> starting vacuum...end.
> setrandom: \setrandom maximum is less than minimum
> client 0 aborted in state 1; execution of meta-command failed
> transaction type: SELECT only
> scaling factor: 0
> query mode: simple
> number of clients: 1
> number of threads: 1
> duration: 20 s
> number of transactions actually processed: 0
>
> I can otherwise use the database without issue.

The only explanation I can think of here is that pgbench on startup
queries one of the tables to figure out the scale factor, and it seems
to be coming up with scaling factor 0, suggesting that the table was
perhaps truncated.  If the tables are unlogged, that's expected.
Otherwise, it sounds like a serious bug in recovery.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [PATCH] Refactoring of LWLock tranches
Next
From: Alvaro Herrera
Date:
Subject: Re: GIN pending list clean up exposure to SQL