On 10 April 2018 at 08:55, Tom Lane <t...@sss.pgh.pa.us> wrote: > Alvaro Herrera <alvhe...@alvh.no-ip.org> writes: >> David Rowley wrote: >>> Okay, I've written and attached a fix for this. I'm not 100% certain >>> that this is the cause of the problem on pademelon, but the code does >>> look wrong, so needs to be fixed. Hopefully, it'll make pademelon >>> happy, if not I'll think a bit harder about what might be causing that >>> instability. > >> Pushed it just now. Let's see what happens with pademelon now. > > I've had pademelon's host running a "make installcheck" loop all day > trying to reproduce the problem. I haven't gotten a bite yet (although > at 15+ minutes per cycle, this isn't a huge number of tests). I think > we were remarkably (un)lucky to see the problem so quickly after the > initial commit, and I'm afraid pademelon isn't going to help us prove > much about whether this was the same issue. > > This does remind me quite a bit though of the ongoing saga with the > postgres_fdw test instability. Given the frequency with which that's > failing in the buildfarm, you would not think it's impossible to > reproduce outside the buildfarm, and yet I'm here to tell you that > it's pretty damn hard. I haven't succeeded yet, and that's not for > lack of trying. Could there be something about the buildfarm > environment that makes these sorts of things more likely?
coypu just demonstrated that this was not the cause of the problem [1] I'll study the code a bit more and see if I can think why this might be happening. [1] https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=coypu&dt=2018-04-11%2004%3A17%3A38&stg=install-check-C -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
