From: | Thom Brown <thom(at)linux(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pgbench unusable after crash during pgbench |
Date: | 2015-11-19 16:46:18 |
Message-ID: | CAA-aLv4NZt1a6nBsyrhP_c4uiQ+=XTD099gGSGn9+UiRr+zrdw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 19 November 2015 at 16:11, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Thu, Nov 19, 2015 at 6:03 AM, Thom Brown <thom(at)linux(dot)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(at)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(at)swift:~/Development/postgresql$ pg_ctl start
>> pg_ctl: another server might be running; trying to start server anyway
>> server starting
>> thom(at)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
From | Date | Subject | |
---|---|---|---|
Next Message | Jaime Casanova | 2015-11-19 16:47:33 | Re: GIN pending list clean up exposure to SQL |
Previous Message | Mike Blackwell | 2015-11-19 16:44:27 | Re: Re: In-core regression tests for replication, cascading, archiving, PITR, etc. |