Alvaro Herrera 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 without all the
> san
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
Tom Lane wrote:
> Andres Freund 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 long wanted to
Andres Freund 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 without this test alt
On December 26, 2014 6:10:51 PM CET, Alvaro Herrera
wrote:
>Tom Lane wrote:
>> Alvaro Herrera writes:
>> > Tom Lane wrote:
>> >> Alvaro Herrera writes:
>> >>> Hm, maybe we can drop the event trigger explicitely first, then
>wait a
>> >>> little bit, then drop the remaining objects with DROP CAS
Tom Lane wrote:
> Alvaro Herrera writes:
> > Tom Lane wrote:
> >> Alvaro Herrera 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 timing har
Alvaro Herrera writes:
> Tom Lane wrote:
>> Alvaro Herrera 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 timing harder to hit. Another
>> proces
Tom Lane wrote:
> Alvaro Herrera 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
Alvaro Herrera 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 trigger when the DROP
Tom Lane wrote:
> Alvaro Herrera 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.
>
>
Alvaro Herrera 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 course move it to a
Tom Lane wrote:
> Andres Freund 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
> the
Andres Freund 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 it frickin insane to
Andres Freund 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 immediate issue, it s
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
I wrote:
> These two recent failures look suspiciously similar:
> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jaguarundi&dt=2014-12-24%2021%3A03%3A05
> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=kouprey&dt=2014-12-25%2018%3A43%3A17
And I'd barely finished posting that before
These two recent failures look suspiciously similar:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jaguarundi&dt=2014-12-24%2021%3A03%3A05
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=kouprey&dt=2014-12-25%2018%3A43%3A17
to wit:
*** /usr/home/pgbf/buildenv/HEAD/pgsql.build/src/
17 matches
Mail list logo
