On December 26, 2014 6:10:51 PM CET, Alvaro Herrera <alvhe...@2ndquadrant.com> 
>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. 
>> >> 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
>> > 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
>> > with long-running transactions.)
>> Whether that's sane or not, the whole problem is so far out-of-scope
>> 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
>> 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:

Reply via email to