Re: LWLock deadlock and gdb advice
| От | Jeff Janes |
|---|---|
| Тема | Re: LWLock deadlock and gdb advice |
| Дата | |
| Msg-id | CAMkU=1wN=0M1QsOO0giobNq=p2j89rkEKPezemQRtAeCobaGYg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: LWLock deadlock and gdb advice (Andres Freund <andres@anarazel.de>) |
| Ответы |
Re: LWLock deadlock and gdb advice
|
| Список | pgsql-hackers |
On Tue, Jul 28, 2015 at 7:06 AM, Andres Freund <andres@anarazel.de> wrote:
Hi,
On 2015-07-19 11:49:14 -0700, Jeff Janes wrote:
> After applying this patch to commit fdf28853ae6a397497b79f, it has survived
> testing long enough to convince that this fixes the problem.
What was the actual workload breaking with the bug? I ran a small
variety and I couldn't reproduce it yet. I'm not saying there's no bug,
I just would like to be able to test my version of the fixes...
It was the torn-page fault-injection code here:
It is not a minimal set, I don't know if all parts of this are necessary to rerproduce it. The whole crash-recovery cycling might not even be important.
Compiled with:
./configure --enable-debug --with-libxml --with-perl --with-python --with-ldap --with-openssl --with-gssapi --prefix=/home/jjanes/pgsql/torn_bisect/
(Also with or without --enable-cassert).
I just ran "sh do.sh >& do.out" and eventually it stopped producing output, and I find everything hung up.
Cheers,
Jeff
В списке pgsql-hackers по дате отправления: