On Tue, Mar 23, 2010 at 05:10, Takahiro Itagaki
wrote:
>
> Greg Smith 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.
My guess
Greg Smith 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 Center
--
Sent
Takahiro Itagaki wrote:
Greg Smith 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 looks like it passed
Greg Smith 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 pgsql-hackers mailing li
Takahiro Itagaki wrote:
The log filenames are "pgbench_log.."
for each thread, but the first thread (including single-threaded) still uses
"pgbench_log." for the name because of compatibility.
Attached is an updated version that I think is ready to commit. Only
changes are docs--I rewrote
Takahiro Itagaki wrote:
> > > 2. Use per-thread log files.
> > > File names would be "pgbench_log..".
Here is a patch to implement per-thread log files for pgbench -l.
The log filenames are "pgbench_log.."
for each thread, but the first thread (including single-threaded) still uses
"pgb
Tom Lane wrote:
> Takahiro Itagaki 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.
> > 2. Use per-thread log files.
> > Fi
Takahiro Itagaki writes:
> Greg Smith 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 pthrea
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..".
I'm concerned that the locking itself will turn int
Greg Smith 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
multi-threaded
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 o
Greg Smith 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 implementation, which is what
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 of
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 fe
14 matches
Mail list logo
