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 09:35:31 |
Message-ID: | alpine.DEB.2.21.1911071012320.20647@lancre |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
> 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.
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.
I agree that it should be documented.
Attached patch adds a doc and moves the check where it should be, and
modifies a test with an explicit no-op space initialization step.
--
Fabien.
Attachment | Content-Type | Size |
---|---|---|
pgbench-check-init-1.patch | text/x-diff | 2.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2019-11-07 09:40:19 | Re: [Proposal] Global temporary tables |
Previous Message | 曾文旌 (义从) | 2019-11-07 09:30:27 | Re: [Proposal] Global temporary tables |