Re: pgbench - extend initialization phase control

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: btkimurayuzk <btkimurayuzk(at)oss(dot)nttdata(dot)com>, 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-11-07 11:18:29
Message-ID: alpine.DEB.2.21.1911071209260.20647@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Hello,

>> I think that the actual oversight is that the checkInitSteps should be
>> called at the beginning of processing initialization steps rather than
>> while processing -I, because currently other places modify the
>> initialization string (no-vacuum, foreign key) and thus are not checked.
>
> As far as I read the code, runInitSteps() does the check. If the initialization
> steps string contains unrecognized character, runInitSteps() emits an error.

Sure, but the previous step have been executed and committed, the point of
the check is to detect the issue before starting the execution.

> * (We could just leave it to runInitSteps() to fail if there are wrong
> * characters, but since initialization can take awhile, it seems friendlier
> * to check during option parsing.)
>
> The above comment in checkInitSteps() seems to explain why
> checkInitSteps() is called at the beginning of processing initialization
> steps.

Yep, the comment is right in the motivation, but not accurate anymore wrt
the submitted patch. V2 attached updates this comment.

--
Fabien.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2019-11-07 11:33:44 Re: Reorderbuffer crash during recovery
Previous Message Tomas Vondra 2019-11-07 11:18:23 Re: Reorderbuffer crash during recovery