Re: thread safety on clients

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Smith <greg(at)2ndquadrant(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: thread safety on clients
Date: 2009-12-11 04:22:23
Message-ID: 9269.1260505343@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greg Smith <greg(at)2ndquadrant(dot)com> writes:
> The "-j" option is the recent addition to pgbench that causes it to
> launch multiple client threads when enabled, each handling a subset of
> the transactions. There's blocks of codes in pgbench.c now that depend
> on having sane values for thread safety in libpq. That it may be
> detecting the wrong thing and operating in an unsafe way after the
> recent change is what Peter's suggesting. This is good, actually,
> because I don't think we had many client-side thread-safety tests
> floating around to catch problems in this area before.

The report showed an assert inside the backend. It really doesn't
matter *how* broken pgbench might be, it should not be able to cause
that. My bet is that the real problem was a build inconsistency in
the backend. Does "make distclean" and rebuild make it go away?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-12-11 04:23:45 Re: Largeobject Access Controls (r2460)
Previous Message Greg Smith 2009-12-11 03:48:45 Re: SE-PostgreSQL/Lite Review