Re: Some other odd buildfarm failures

Tom Lane wrote:
> 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.

I think dropping the part involving an event trigger from the test is
reasonable.  I will go do that.

> If you want to work on making DROP EVENT TRIGGER safer in the long run,
> that can be a separate activity.

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.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services