pgbench unusable after crash during pgbench

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers