On Fri, May 6, 2016 at 11:24 AM, Andres Freund <andres@anarazel.de> wrote:
>
>> I have been trying (and failing) to reproduce the problem in more
>> recent releases, with and without cassert. Here is pg_config output
>> of one of my current attempts:
>
> If you say "recent releases" you mean that you've not been able to
> reproduce it in 9.5, 9.4, ..., not that the issue has vanished in
> master, right?
Sorry, I meant recent commits, not releases. I have not been able to
reproduce it in master (anything after 8f1911d5e6), but I also can't
find the commit which fixed it, because I don't know how many hours of
running without an error is enough to declare it good. I've already
gotten burned by that by declaring 8f1911d5e6 good once, only to find
out it was still bad just with a lower probability of finding it.
I also can't reproduce it in 9.5, but I wouldn't expect it to given
the large changes in the way GIN indexes operates between 9.5 and 9.6,
which completely changes the timing and types of races (even ones
outside of the GIN code) one might expect to see. I'm pretty sure I
would have caught it during 9.5's beta if it were findable with this
test, as this test was run back then in pretty close to the current
form. I'm not saying their isn't a bug in 9.5, just that if there is
this test is not efficient at invoking it.
So the issue *has* vanished in master, but without knowing what fixed
it I have no confidence it was actually fixed, rather than the test
just stopped being effective.
What I plan on doing now is going back to the part of the commit
history where I could reproduce it reliably, and start throwing
unnecessary things of the ./configure and the postgresql.conf to see
what the minimal configuration is at which I can reproduce it.
Sorry for the confusion.
Cheers,
Jeff