On 10 April 2018 at 08:55, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Alvaro Herrera <alvherre@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
