From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Greg Smith <greg(at)2ndquadrant(dot)com>, 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 02:23:38 |
Message-ID: | 200912110223.nBB2NcE27768@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
From | Date | Subject | |
---|---|---|---|
Next Message | Takahiro Itagaki | 2009-12-11 02:35:56 | Re: EXPLAIN BUFFERS |
Previous Message | Bruce Momjian | 2009-12-11 02:21:41 | Re: enable-thread-safety defaults? |