Re: pgbench unusable after crash during pgbench

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: pgbench unusable after crash during pgbench
Дата
Msg-id CA+TgmobJDdwd6TiDeLKfuXP-brK8Hz-nvh1WaKm8mDCgQd662g@mail.gmail.com
обсуждение исходный текст
Ответ на pgbench unusable after crash during pgbench  (Thom Brown <thom@linux.com>)
Ответы Re: pgbench unusable after crash during pgbench
Список pgsql-hackers
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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [PATCH] Refactoring of LWLock tranches
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: GIN pending list clean up exposure to SQL