On Tue, Mar 23, 2010 at 05:10, Takahiro Itagaki
itagaki.takah...@oss.ntt.co.jp wrote:
Greg Smith g...@2ndquadrant.com wrote:
By the way: the pgbench.sgml that you committed looks like it passed
through a system that added a CR to every line in it. Probably not the
way you intended to commit
Greg Smith g...@2ndquadrant.com wrote:
Attached is an updated version that I think is ready to commit. Only
changes are docs--I rewrote those to improve the wording some.
Thanks for the correction. Applied.
Regards,
---
Takahiro Itagaki
NTT Open Source Software Center
--
Sent via
Takahiro Itagaki wrote:
Greg Smith g...@2ndquadrant.com wrote:
Attached is an updated version that I think is ready to commit. Only
changes are docs--I rewrote those to improve the wording some.
Thanks for the correction. Applied.
By the way: the pgbench.sgml that you committed
Greg Smith g...@2ndquadrant.com wrote:
By the way: the pgbench.sgml that you committed looks like it passed
through a system that added a CR to every line in it. Probably not the
way you intended to commit that.
Oops, fixed. Thanks.
Regards,
---
Takahiro Itagaki
NTT Open Source Software
Takahiro Itagaki wrote:
The log filenames are pgbench_log.main-process-id.thread-serial-number
for each thread, but the first thread (including single-threaded) still uses
pgbench_log.main-process-id for the name because of compatibility.
Attached is an updated version that I think is ready
Just noticed a problem popping up sometimes with the new multi-threaded
pgbench. This is on a Linux RPM build (the alpha4 set) compiled with
'--disable-thread-safety'. Still trying to nail down whether that's a
requirement for this problem to appear or not. I did most of my review
of this
Greg Smith wrote:
Just noticed a problem popping up sometimes with the new
multi-threaded pgbench. This is on a Linux RPM build (the alpha4 set)
compiled with '--disable-thread-safety'. Still trying to nail down
whether that's a requirement for this problem to appear or not. I did
most
Greg Smith g...@2ndquadrant.com writes:
Looks like sometimes a client is only getting part of its line written
out before getting stomped on by the next one. I think one of the
assumptions being made about how to safely write to this log file may be
broken by the multi-process
On 3/15/10 8:41 AM, Greg Smith wrote:
Just noticed a problem popping up sometimes with the new multi-threaded
pgbench. This is on a Linux RPM build (the alpha4 set) compiled with
'--disable-thread-safety'. Still trying to nail down whether that's a
requirement for this problem to appear or
Greg Smith g...@2ndquadrant.com wrote:
It looks like the switch between clients running on separate workers can
lead to a mix of their respective lines showing up though.
Oops. There might be two solutions for the issue:
1. Use explicit locks. The lock primitive will be pthread_mutex for
Takahiro Itagaki wrote:
1. Use explicit locks. The lock primitive will be pthread_mutex for
multi-threaded implementations or semaphore for multi-threaded ones.
2. Use per-thread log files.
File names would be pgbench_log.main-process-id.thread-id.
I'm concerned that the
Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp writes:
Greg Smith g...@2ndquadrant.com wrote:
It looks like the switch between clients running on separate workers can
lead to a mix of their respective lines showing up though.
Oops. There might be two solutions for the issue:
1. Use
Tom Lane t...@sss.pgh.pa.us wrote:
Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp writes:
Oops. There might be two solutions for the issue:
1. Use explicit locks. The lock primitive will be pthread_mutex for
multi-threaded implementations or semaphore for multi-threaded ones.
Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp wrote:
2. Use per-thread log files.
File names would be pgbench_log.main-process-id.thread-id.
Here is a patch to implement per-thread log files for pgbench -l.
The log filenames are pgbench_log.main-process-id.thread-serial-number
14 matches
Mail list logo
