On Wed, 2009-04-22 at 13:53 -0400, Alvaro Herrera wrote: > Another thing we could do is make autovacuum log something about those, > similar to what it does to temp tables. And if one of them gets too > near Xid wraparound, kill it.
As I said in my reply to Joshua, I don't think killing a prepared transaction is consistent with the safety people expect from 2PC. However, if it's near wraparound time, that could be considered an exceptional case I suppose, and if we don't have a better way to avoid getting the system in a very bad state, it might be acceptable. I like the idea of logging some kind of warning a long time before it becomes a real problem. Should the staleness of a prepared transaction be measured in time or xid age or both? Maybe have a reasonable default of a few minutes or a couple thousand transactions before it starts issuing warnings? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers