Re: Some other odd buildfarm failures - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Some other odd buildfarm failures
Date
Msg-id 32724.1419612455@sss.pgh.pa.us
Whole thread Raw
In response to Re: Some other odd buildfarm failures  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: Some other odd buildfarm failures  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Tom Lane wrote:
>> Alvaro Herrera <alvherre@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 timing harder to hit.  Another
>> process could be paused at the critical point for longer than whatever "a
>> little bit" is.

> Yeah, I was thinking we could play some games with the currently running
> XIDs from a txid_snapshot or some such, with a reasonable upper limit on
> the waiting time (for the rare cases with a server doing other stuff
> with long-running transactions.)

Whether that's sane or not, the whole problem is so far out-of-scope for
a test of pg_get_object_address() that it's not even funny.  I think
we should adopt one of the two fixes I recommended and call it good.
If you want to work on making DROP EVENT TRIGGER safer in the long run,
that can be a separate activity.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Some other odd buildfarm failures
Next
From: Bruce Momjian
Date:
Subject: Re: What exactly is our CRC algorithm?