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
