Re: thread safety on clients - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: thread safety on clients
Date
Msg-id 200912110223.nBB2NcE27768@momjian.us
Whole thread Raw
In response to Re: thread safety on clients  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
Bruce Momjian wrote:
> Greg Smith wrote:
> > Bruce Momjian wrote:
> > > Peter Eisentraut wrote:
> > >   
> > >>> if i remove the -j option then it runs without a problem
> > >>>       
> > >> Possibly related to the incomplete removal of the enable-thread-safety
> > >> option that I just posted about.
> > >>     
> > >
> > > I thought about that but I can't figure out how that would affect
> > > pgbench.
> > >   
> > 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.
> 
> I can reproduce the crash here so I can see if I can find the cause.
> 
> However, the failure is happening in the _server_.  Threading is
> unrelated to the server itself, only the client.  I suppose the first
> test for me will be to test CVS before the thread change was made.
> 
> The failure is in heap_fill_tuple(), and I am unclear how that assert
> could be getting triggered:
> 
>     CONTEXT:  automatic analyze of table "test.public.pgbench_accounts"
>     TRAP: FailedAssertion("!((data - start) == data_size)", File: "heaptuple.c", Line: 255)
>     TRAP: FailedAssertion("!((data - start) == data_size)", File: "heaptuple.c", Line: 255)
>     TRAP: FailedAssertion("!((data - start) == data_size)", File: "heaptuple.c", Line: 255)
>     LOG:  server process (PID 6076) was terminated by signal 6: Abort trap
>     LOG:  terminating any other active server processes

OK, turns out I did break threading by not defining ENABLE_THREAD_SAFETY
in configure.  I have applied a patch to CVS to fix this.

However, the larger question is how did I crash a backend by not
defining this?  I guess it is possible for a client to crash the server
by having a misconfigured client --- I wasn't aware of that.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: enable-thread-safety defaults?
Next
From: Takahiro Itagaki
Date:
Subject: Re: EXPLAIN BUFFERS