Dear Nagata-san,
> As I understand it, the current patch aims to allow continuation only after
> SQL-level
> errors, such as constraint violations. That seems reasonable, as it can simulate
> the
> behavior of applications that ignore or retry such errors (even though retries are
> not
> implemented in the current patch).
Yes, no one has objections to retry in this case. This is a main part of the proposal.
> However, I'm not sure it's reasonable to allow continuation after other types of
> errors,
> such as misuse of meta-commands or unexpected errors during their execution,
> since these
> wouldn't simulate any real application behavior and would more likely indicate a
> failure
> in the benchmarking process itself.
I have a concern for \gset metacommand.
According to the doc and source code, \gset assumed that executed command surely
returns a tuple:
```
if (meta == META_GSET && ntuples != 1)
{
/* under \gset, report the error */
pg_log_error("client %d script %d command %d query %d: expected one row, got %d",
st->id, st->use_file, st->command, qrynum, PQntuples(res));
st->estatus = ESTATUS_META_COMMAND_ERROR;
goto error;
}
```
But sometimes the SQL may not be able to return tuples or return multiple ones due
to the concurrent transactions. I feel retrying the transaction is very useful
in this case.
Anyway, we must confirm the opinion from the proposer.
[1]: https://github.com/ryogrid/tpcc_like_with_pgbench
Best regards,
Hayato Kuroda
FUJITSU LIMITED
