On Fri, May 6, 2016 at 11:24 AM, Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
