Prev: [HACKERS] how to use advanced gist options
Next: [HACKERS] WIP: simple allocator
From: Andrew Dunstan on 15 Mar 2010 11:58


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 my review of this feature with it turned on, and haven't been
> seeing this problem on other systems that are thread safe. Not sure
> yet if that's cause and effect or coincidence yet.
>
>

We had to turn handsprings to prevent this sort of effect with the
logging collector, which was a requirement of being able to implement
CSV logging sanely. So I'm not surprised by this report.

cheers

andrew

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

From: Tom Lane on 15 Mar 2010 12:06
Greg Smith <greg(a)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 implementation, which is what you get when
> thread-safety is not available.

pgbench doesn't make any effort at all to avoid interleaved writes on
that file. I don't think there is anything much that can be done about
it when you are using the forked-processes implementation. It's
probably possible for it to show up on the multi-threads version too,
depending on how hard libc tries to interlock stdio calls.

regards, tom lane

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

From: Josh Berkus on 15 Mar 2010 18:47
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 not. I did most of my review
> of this feature with it turned on, and haven't been seeing this problem
> on other systems that are thread safe. Not sure yet if that's cause and
> effect or coincidence yet.

For my part, telling people that multi-thread pgbench doesn't work
correctly on systems which are not thread-safe seems perfectly OK.


--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com

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

From: Takahiro Itagaki on 15 Mar 2010 20:46

Greg Smith <greg(a)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
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>".

Which is better, or another idea?

Regards,
---
Takahiro Itagaki
NTT Open Source Software Center



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

From: Greg Smith on 15 Mar 2010 21:59
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 locking itself will turn into a new pgbench
bottleneck, just as we're clearing the point where it's not for the
first time in a while. And that sounds like it has its own potential
risks/complexity involved.

I could live with per-thread log files. I think my pgbench-tools is the
main consumer of these latency logs floating around right now, I just
pushed a 9.0 update to handle the multiple workers option today that
discovered this). It doesn't make any difference to what I'm doing how
many file I have to process. Just a few lines of extra shell code for
me to pull the rest into the import. That seems like the simplest
solution that's guaranteed to work, just push the problem onto the
client side instead where it's easier to deal with.

Unless someone feels strongly that these have to be interleaved into one
file, based on Andrew's suggestion that this is a hard problem to get
right and Tom's suggestion that this might even extend into the proper
threaded version too, I think a log file per worker is the easiest way
out of this.

--
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Support
greg(a)2ndQuadrant.com www.2ndQuadrant.us


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

 |  Next  |  Last
Pages: 1 2 3
Prev: [HACKERS] how to use advanced gist options
Next: [HACKERS] WIP: simple allocator