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 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 -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers