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

Robert Haas <rhaas@postgresql.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

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

On Wed, Nov 9, 2016 at 4:51 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Robert Haas <rhaas@postgresql.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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Robert Haas <robertmhaas@gmail.com> writes:

On Wed, Nov 9, 2016 at 4:51 PM, Tom Lane <tgl@sss.pgh.pa.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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Thu, Nov 10, 2016 at 12:08 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Robert Haas <robertmhaas@gmail.com> writes:

On Wed, Nov 9, 2016 at 4:51 PM, Tom Lane <tgl@sss.pgh.pa.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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Wed, Nov 9, 2016 at 10:08 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Robert Haas <robertmhaas@gmail.com> writes:

On Wed, Nov 9, 2016 at 4:51 PM, Tom Lane <tgl@sss.pgh.pa.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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers