pgsql: pgbench: Allow the transaction log file prefix to be changed.

pgbench: Allow the transaction log file prefix to be changed.

Masahiko Sawada, reviewed by Fabien Coelho and Beena Emerson, with
some a bit of wordsmithing and cosmetic adjustment by me.

Branch
------
master

Details
-------
http://git.postgresql.org/pg/commitdiff/41124a91e61fc6d9681c1e8b15ba30494e84d643

Modified Files
--------------
doc/src/sgml/ref/pgbench.sgml | 26 +++++++++++++++++++-------
src/bin/pgbench/pgbench.c | 20 ++++++++++++++++++--
2 files changed, 37 insertions(+), 9 deletions(-)

Robert Haas <rhaas(at)postgresql(dot)org> writes:
> pgbench: Allow the transaction log file prefix to be changed.

Perhaps the "logpath" buffer that the filename is constructed in
needs to be made bigger. 64 bytes was obviously enough with the
old pattern, but it's not with the new.

regards, tom lane

On Wed, Nov 9, 2016 at 4:51 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <rhaas(at)postgresql(dot)org> writes:
>> pgbench: Allow the transaction log file prefix to be changed.
>
> Perhaps the "logpath" buffer that the filename is constructed in
> needs to be made bigger. 64 bytes was obviously enough with the
> old pattern, but it's not with the new.

Oops, yes, that seems like a good idea. How about 64 -> MAXPGPATH?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Nov 9, 2016 at 4:51 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Perhaps the "logpath" buffer that the filename is constructed in
>> needs to be made bigger. 64 bytes was obviously enough with the
>> old pattern, but it's not with the new.

> Oops, yes, that seems like a good idea. How about 64 -> MAXPGPATH?

If we want to stick with the fixed-size-buffer-on-stack approach,
that would be the thing to use. psprintf is another possibility,
though that would add a malloc/free cycle.

regards, tom lane

On Thu, Nov 10, 2016 at 12:08 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Wed, Nov 9, 2016 at 4:51 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Perhaps the "logpath" buffer that the filename is constructed in
>>> needs to be made bigger. 64 bytes was obviously enough with the
>>> old pattern, but it's not with the new.
>
>> Oops, yes, that seems like a good idea. How about 64 -> MAXPGPATH?
>
> If we want to stick with the fixed-size-buffer-on-stack approach,
> that would be the thing to use. psprintf is another possibility,
> though that would add a malloc/free cycle.

MAXPGPATH is used quite a lot in the binaries of src/bin/, just using
that seems fine to me.. My 2c.
--
Michael

On Wed, Nov 9, 2016 at 10:08 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Wed, Nov 9, 2016 at 4:51 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Perhaps the "logpath" buffer that the filename is constructed in
>>> needs to be made bigger. 64 bytes was obviously enough with the
>>> old pattern, but it's not with the new.
>
>> Oops, yes, that seems like a good idea. How about 64 -> MAXPGPATH?
>
> If we want to stick with the fixed-size-buffer-on-stack approach,
> that would be the thing to use. psprintf is another possibility,
> though that would add a malloc/free cycle.

I don't think the performance cost of a malloc/free cycle would be
noticeable, but I don't see much point in it, either. It's likely
that, if you hadn't notice this by inspection, we could have gone a
few years before anyone ran afoul of the 64-character limit. Now,
MAXPGPATH is 1024, and I do not know too many people who have a real
need for pathnames over 1024 characters. I think we may as well just
keep it simple.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company