Thread: pgbench unusable after crash during pgbench
Hi, 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 domainsocket "/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. Thom
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
On 19 November 2015 at 16:11, Robert Haas <robertmhaas@gmail.com> wrote: > 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. Actually yes, that's something I appear to have omitted. I was using unlogged tables, which makes sense now. Even so, the errors generated are not at all helpful, and I would expect pgbench to handle this case explicitly. Thom
Thom Brown <thom@linux.com> writes:
> On 19 November 2015 at 16:11, Robert Haas <robertmhaas@gmail.com> wrote:
>> 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.
> Actually yes, that's something I appear to have omitted. I was using
> unlogged tables, which makes sense now.
> Even so, the errors generated are not at all helpful, and I would
> expect pgbench to handle this case explicitly.
Meh ... it's not very clear how to improve that. The ":scale" variable is
set from "select count(*) from pgbench_branches"; it's not immediately
obvious that zero should not be an allowed result. Then the :scale value
is used as the upper limit in a \setrandom script command, and the
complaint about that seems fairly on point.
I do agree that pgbench could do more in the way of showing you the script
command (and line number, maybe) that failed. Patches welcome.
regards, tom lane