From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Andres Freund <andres(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Some other odd buildfarm failures |
Date: | 2014-12-26 16:47:35 |
Message-ID: | 32724.1419612455@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> Tom Lane wrote:
>> Alvaro Herrera <alvherre(at)2ndquadrant(dot)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.
If you want to work on making DROP EVENT TRIGGER safer in the long run,
that can be a separate activity.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2014-12-26 17:05:34 | Re: What exactly is our CRC algorithm? |
Previous Message | Alvaro Herrera | 2014-12-26 16:35:46 | Re: Some other odd buildfarm failures |