Re: Some other odd buildfarm failures
От | Tom Lane |
---|---|
Тема | Re: Some other odd buildfarm failures |
Дата | |
Msg-id | 32724.1419612455@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Some other odd buildfarm failures (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: Some other odd buildfarm failures
|
Список | pgsql-hackers |
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. If you want to work on making DROP EVENT TRIGGER safer in the long run, that can be a separate activity. regards, tom lane
В списке pgsql-hackers по дате отправления: