From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
---|---|
To: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
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 10:13:41 |
Message-ID: | CAHGQGwHMKcASmuXAJ=G2FQgDRKpCr-a=+r=H6pKnQ+d-Eb=1Pw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Nov 7, 2019 at 6:35 PM Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> wrote:
>
>
> Hello Masao-san,
>
> >> I do not think that this is desirable. It would be a regression, and
> >> allowing a no-op is not an issue in anyway.
> >
> > Why is that regression, you think?
>
> Because "pgbench -I ' d'" currently works and it would cease to work after
> the patch.
If the behavior has been documented and visible to users,
I agree that it should not be dropped for compatibility basically.
But in this case, that was not.
> > I think that's an oversight. If I'm missing something and accepting a
> > blank character as no-op in also checkInitSteps() is really necessary
> > for some reasons, which should be documented. But, if so, another
> > question is; why should only blank character be treated as no-op, in
> > checkInitSteps()?
>
> The idea is to have one character that can be substituted to remove any
> operation.
Probably I understand that idea is necessary in the internal of pgbench
because pgbench internally may modify the initialization steps string.
But I'm not sure why it needs to be exposed, yet.
> On principle, allowing a no-op character, whatever the choice, is a good
> idea, because it means that the caller can take advantage of that if need
> be.
>
> 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.
* (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.
Regards,
--
Fujii Masao
From | Date | Subject | |
---|---|---|---|
Next Message | Dilip Kumar | 2019-11-07 10:19:51 | Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions |
Previous Message | Peter Eisentraut | 2019-11-07 10:10:19 | Re: tableam vs. TOAST |