Thread: Re: Configure with thread sanitizer fails the thread test
Ewan Higgs wrote: > So I changed volatile to _Atomic and continued (patch is in > thread_test_atomic.patch). I then ran it against sqlsmith. The good > news: I didn't happen to find any problems in normal use. The bad > news: I did find a lot of warnings about improper use of functions > like malloc and free from signal handlers. There's a reason why we don't offer a threaded server ... The postmaster process in particular runs in a rather unusual arrangement, where most of the interesting stuff does happen in signal handlers. I doubt there's any chance that we would make it run in a threaded environment. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 2015-08-17 14:31:24 -0300, Alvaro Herrera wrote: > The postmaster process in particular runs in a rather unusual > arrangement, where most of the interesting stuff does happen in signal > handlers. FWIW, I think it might be worthwhile to convert postmaster into a loop over a process local latch, with that latch being set in signal handlers. My feeling is that that'd simplify the code rather significantly. I'm not 100% it's worth the code churn, but it'd definitely be easier to understand. Thread sanitizer isn't the first analysis tool that has problems coping with forks in signal handlers btw, valgrind on amd64 for a long while had misaligned stacks in the children afterwards leading to very odd crashes. Greetings, Andres Freund
On Mon, Aug 17, 2015 at 3:02 PM, Andres Freund <andres@anarazel.de> wrote: > On 2015-08-17 14:31:24 -0300, Alvaro Herrera wrote: >> The postmaster process in particular runs in a rather unusual >> arrangement, where most of the interesting stuff does happen in signal >> handlers. > > FWIW, I think it might be worthwhile to convert postmaster into a loop > over a process local latch, with that latch being set in signal > handlers. My feeling is that that'd simplify the code rather > significantly. I'm not 100% it's worth the code churn, but it'd > definitely be easier to understand. Thread sanitizer isn't the first > analysis tool that has problems coping with forks in signal handlers > btw, valgrind on amd64 for a long while had misaligned stacks in the > children afterwards leading to very odd crashes. Yeah, I'm a little worried about whether we'd destabilize things by changing them in that way, but if we could avoid that pitfall I suspect we'd end up better off. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company