On 10/10/2014 04:16 AM, MauMau wrote:
> From: "Craig Ringer" <craig@2ndquadrant.com>
>> It'd be interesting and useful to run this test on a debug build of
>> PostgreSQL, i.e. one compiled against the debug version of the C library
>> and with full debuginfo not just minimal .pdb.
>
> Although I'm not sure the user can do this now, I'll ask him anyway.
It sounds like they've produced a test case, so they should be able to
with a bit of luck.
Or even better, send you the test case.
>> How were the stacks captured - what tool?
>
> According to his mail, Windbg or userdump.exe. I'll ask him about this.
Thanks. The stack trace looks fairly sane, i.e. there's nothing
obviously out of whack at a glance, but I tend to get more informative
traces from Visual Studio debugging sessions.
Your next step here really needs to be to make this reproducible against
a debug build. Then see if reverting the xlog scalability work actually
changes the behaviour, given that you hypothesised that it could be
involved.
As I said off-list, if you can narrow the test case down to something
that can be reproduced more quickly, you could also git-bisect to seek
the commit at fault. Even if the test case takes an hour, that's still
viable:
$ git bisect start
$ git bisect bad
$ git bisect good REL9_3_RC1
Bisecting: a merge base must be tested
[e472b921406407794bab911c64655b8b82375196] Avoid deadlocks during
insertion into SP-GiST indexes.
$ git bisect good
Bisecting: 1026 revisions left to test after this (roughly 10 steps)
...
Thanks to the magic of binary search.
-- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
