Thom Brown <t...@linux.com> writes: > On 19 November 2015 at 16:11, Robert Haas <robertmh...@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