On Thu, Jul 16, 2015 at 12:03 AM, Jeff Janes <jeff.ja...@gmail.com> wrote:

> On Wed, Jul 15, 2015 at 8:44 AM, Heikki Linnakangas <hlinn...@iki.fi>
> wrote:
>> Both. Here's the patch.
>> Previously, LWLockAcquireWithVar set the variable associated with the
>> lock atomically with acquiring it. Before the lwlock-scalability changes,
>> that was straightforward because you held the spinlock anyway, but it's a
>> lot harder/expensive now. So I changed the way acquiring a lock with a
>> variable works. There is now a separate flag, LW_FLAG_VAR_SET, which
>> indicates that the current lock holder has updated the variable. The
>> LWLockAcquireWithVar function is gone - you now just use LWLockAcquire(),
>> which always clears the LW_FLAG_VAR_SET flag, and you can call
>> LWLockUpdateVar() after that if you want to set the variable immediately.
>> LWLockWaitForVar() always waits if the flag is not set, i.e. it will not
>> return regardless of the variable's value, if the current lock-holder has
>> not updated it yet.
> I ran this for a while without casserts and it seems to work.  But with
> casserts, I get failures in the autovac process on the GIN index.
> I don't see how this is related to the LWLock issue, but I didn't see it
> without your patch.  Perhaps the system just didn't survive long enough to
> uncover it without the patch (although it shows up pretty quickly).  It
> could just be an overzealous Assert, since the casserts off didn't show
> problems.

> bt and bt full are shown below.
> Cheers,
> Jeff
> #0  0x0000003dcb632625 in raise () from /lib64/libc.so.6
> #1  0x0000003dcb633e05 in abort () from /lib64/libc.so.6
> #2  0x0000000000930b7a in ExceptionalCondition (
>     conditionName=0x9a1440 "!(((PageHeader) (page))->pd_special >=
> (__builtin_offsetof (PageHeaderData, pd_linp)))", errorType=0x9a12bc
> "FailedAssertion",
>     fileName=0x9a12b0 "ginvacuum.c", lineNumber=713) at assert.c:54
> #3  0x00000000004947cf in ginvacuumcleanup (fcinfo=0x7fffee073a90) at
> ginvacuum.c:713

It now looks like this *is* unrelated to the LWLock issue.  The assert that
it is tripping over was added just recently (302ac7f27197855afa8c) and so I
had not been testing under its presence until now.  It looks like it is
finding all-zero pages (index extended but then a crash before initializing
the page?) and it doesn't like them.

(gdb) f 3
(gdb) p *(char[8192]*)(page)
$11 = '\000' <repeats 8191 times>

Presumably before this assert, such pages would just be permanently



Reply via email to