On December 26, 2014 6:10:51 PM CET, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: >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.
Can't we just move the test to run without parallelism? Its quite quick, so I don't it'd have noticeable consequences timewise. -- Please excuse brevity and formatting - I am writing this on my mobile phone. Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
