Re: pgbench unusable after crash during pgbench

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thom Brown <thom(at)linux(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pgbench unusable after crash during pgbench
Date: 2015-11-19 16:58:40
Message-ID: 10341.1447952320@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thom Brown <thom(at)linux(dot)com> writes:
> On 19 November 2015 at 16:11, Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2015-11-19 18:39:22 Re: COPY (INSERT/UPDATE/DELETE .. RETURNING ..)
Previous Message Jaime Casanova 2015-11-19 16:57:18 Re: GIN pending list clean up exposure to SQL