On 19 November 2015 at 16:11, Robert Haas <robertmh...@gmail.com> wrote: > On Thu, Nov 19, 2015 at 6:03 AM, Thom Brown <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers