On December 26, 2014 6:10:51 PM CET, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
>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.
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
