Re: pgbench - extend initialization phase control

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: btendouan <btendouan(at)oss(dot)nttdata(dot)com>, "ibrar(dot)ahmad(at)gmail(dot)com:" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pgbench - extend initialization phase control
Date: 2019-10-24 05:04:22
Message-ID: CAHGQGwH8k57JUekDqe2EzOGEnwKuyQFL6xFVxAxVNQLRjJsFkg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Oct 17, 2019 at 8:09 PM Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> wrote:
>
>
> Hello,
>
> > Failed regression test. It's necessary to change the first a in “allowed
> > step characters are” to uppercase A in the regression test of
> > 002_pgbench_no_server.pl.
>
> Argh. I think I ran the test, then stupidly updated the message afterwards
> to better match best practices, without rechecking:-(
>
> > The behavior of "g" is different between v12 and the patche, and
> > backward compatibility is lost. In v12, BEGIN and COMMIT are specified
> > only by choosing "g". It's a problem that backward compatibility is
> > lost.
>
> Somehow yes, but I do not see this as an actual problem from a functional
> point of view: it just means that if you use a 'dtgvp' with the newer
> version and if the inserts were to fail, then they are not under an
> explicit transaction, so previous inserts are not cleaned up. However,
> this is a pretty unlikely case, and anyway the error is reported, so any
> user would be expected not to go on after the initialization phase.
>
> So basically I do not see the very small regression for an unlikely corner
> case to induce any problem in practice.
>
> The benefit of controlling where begin/end actually occur is that it may
> have an impact on performance, and it allows to check that.

I still fail to understand the benefit of addition of () settings.
Could you clarify what case () settings are useful for? You are
thinking to execute all initialization SQL statements within
single transaction, e.g., -I (dtgp), for some reasons?

> > When using ( and ) with the -I, the documentation should indicate that double
> > quotes are required,
>
> Or single quotes, or backslash, if launch from the command line. I added a
> mention of escaping or protection in the doc in that case.

What about using, for example, b (BEGIN) and c (COMMIT) instead
to avoid such restriction?

> > and "v" not be able to enclose in ( and ).
>
> That is a postgresql limitation, which may evolve. There could be others.
> I updated the doc to say that some commands may not work inside an
> explicit transaction.

I think that it's better to check whehter "v" is enclosed with () or not
at the beginning of pgbench, and report an error if it is. Otherwise,
if -I (dtgv) is specified, pgbench reports an error after time-consuming
data generation is performed, and of course that data generation is
rollbacked.

Regards,

--
Fujii Masao

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2019-10-24 05:14:50 Re: Fix comment in XLogFileInit()
Previous Message Michael Paquier 2019-10-24 04:59:29 Re: v12.0: interrupt reindex CONCURRENTLY: ccold: ERROR: could not find tuple for parent of relation ...