Re: [HACKERS] Some other odd buildfarm failures

2014-12-26 Thread Tom Lane
Alvaro Herrera alvhe...@2ndquadrant.com writes: Tom Lane wrote: Still, I don't think this is a reasonable test design. We have absolutely no idea what behaviors are being triggered in the other tests, except that they are unrelated to what those tests think they are testing. I can of

Re: [HACKERS] Some other odd buildfarm failures

2014-12-26 Thread Alvaro Herrera
Tom Lane wrote: Alvaro Herrera alvhe...@2ndquadrant.com writes: Tom Lane wrote: Still, I don't think this is a reasonable test design. We have absolutely no idea what behaviors are being triggered in the other tests, except that they are unrelated to what those tests think they are

Re: [HACKERS] Some other odd buildfarm failures

2014-12-26 Thread Tom Lane
Alvaro Herrera alvhe...@2ndquadrant.com writes: Tom Lane wrote: I've not proven this rigorously, but it seems obvious in hindsight: what's happening is that when the object_address test drops everything with DROP CASCADE, other processes are sometimes just starting to execute the event

Re: [HACKERS] Some other odd buildfarm failures

2014-12-26 Thread Alvaro Herrera
Tom Lane wrote: Alvaro Herrera alvhe...@2ndquadrant.com writes: Tom Lane wrote: I've not proven this rigorously, but it seems obvious in hindsight: what's happening is that when the object_address test drops everything with DROP CASCADE, other processes are sometimes just starting to

Re: [HACKERS] Some other odd buildfarm failures

2014-12-26 Thread Tom Lane
Alvaro Herrera alvhe...@2ndquadrant.com writes: Tom Lane wrote: Alvaro Herrera alvhe...@2ndquadrant.com writes: Hm, maybe we can drop the event trigger explicitely first, then wait a little bit, then drop the remaining objects with DROP CASCADE? As I said, that's no fix; it just makes the

Re: [HACKERS] Some other odd buildfarm failures

2014-12-26 Thread Alvaro Herrera
Tom Lane wrote: Alvaro Herrera alvhe...@2ndquadrant.com writes: Tom Lane wrote: Alvaro Herrera alvhe...@2ndquadrant.com writes: Hm, maybe we can drop the event trigger explicitely first, then wait a little bit, then drop the remaining objects with DROP CASCADE? As I said, that's no

Re: [HACKERS] Some other odd buildfarm failures

2014-12-26 Thread Andres Freund
On December 26, 2014 6:10:51 PM CET, Alvaro Herrera alvhe...@2ndquadrant.com wrote: Tom Lane wrote: Alvaro Herrera alvhe...@2ndquadrant.com writes: Tom Lane wrote: Alvaro Herrera alvhe...@2ndquadrant.com writes: Hm, maybe we can drop the event trigger explicitely first, then wait a

Re: [HACKERS] Some other odd buildfarm failures

2014-12-26 Thread Tom Lane
Andres Freund and...@2ndquadrant.com writes: Can't we just move the test to run without parallelism? Its quite quick, so I don't it'd have noticeable consequences timewise. That just leaves the door open for somebody to add more tests parallel to it in future. TBH, I think we could have done

Re: [HACKERS] Some other odd buildfarm failures

2014-12-26 Thread Alvaro Herrera
Tom Lane wrote: Andres Freund and...@2ndquadrant.com writes: Can't we just move the test to run without parallelism? Its quite quick, so I don't it'd have noticeable consequences timewise. That just leaves the door open for somebody to add more tests parallel to it in future. I've been

Re: [HACKERS] Some other odd buildfarm failures

2014-12-26 Thread Alvaro Herrera
Andres Freund wrote: This sounds like a huge project -- it's not like event triggers are the only objects in the system where this is an issue, is it? I'm sure there is value in fixing it, but I have enough other projects. Can't we just move the test to run without parallelism? Its quite

Re: [HACKERS] Some other odd buildfarm failures

2014-12-26 Thread Tom Lane
Alvaro Herrera alvhe...@2ndquadrant.com writes: Tom Lane wrote: TBH, I think we could have done without this test altogether; but if we're going to have it, a minimum expectation is that it not be hazardous to other tests around it. The number of assertion failures in get_object_address

Re: [HACKERS] Some other odd buildfarm failures

2014-12-25 Thread Tom Lane
I wrote: These two recent failures look suspiciously similar: http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jaguarundidt=2014-12-24%2021%3A03%3A05 http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=koupreydt=2014-12-25%2018%3A43%3A17 And I'd barely finished posting that before

Re: [HACKERS] Some other odd buildfarm failures

2014-12-25 Thread Andres Freund
Hi, On 2014-12-25 16:01:47 -0500, Tom Lane wrote: In any case, it now seems dead certain that this is a recently introduced bug. Andres is fortunate that the first instance occurred before his recent batch of commits, or I'd be on him to revert them. Yes, Phew. These look rather odd. As

Re: [HACKERS] Some other odd buildfarm failures

2014-12-25 Thread Tom Lane
Andres Freund and...@2ndquadrant.com writes: I wonder if it'd not be a good idea if the event trigger code installed a error context callback? Since they can be called in situations we don't routinely expect that'd make diagnosis in many cases easier. +1 ... even if that's not related to the

Re: [HACKERS] Some other odd buildfarm failures

2014-12-25 Thread Tom Lane
Andres Freund and...@2ndquadrant.com writes: My guess is that it's related to d7ee82e50f. It seems realistic that the event trigger added by it to the object_address test can cause errors at varying times. [ squint... ] Event triggers are global across the whole database, aren't they? Isn't

Re: [HACKERS] Some other odd buildfarm failures

2014-12-25 Thread Alvaro Herrera
Tom Lane wrote: Andres Freund and...@2ndquadrant.com writes: My guess is that it's related to d7ee82e50f. It seems realistic that the event trigger added by it to the object_address test can cause errors at varying times. [ squint... ] Event triggers are global across the whole