While cleaning out old mail about two-phase commit, I noticed this
thought from Oliver:
Oliver Jowett <oliver@opencloud.com> writes:
>>> Probably the next question is, do we want a database-side timeout on
>>> how long prepared txns can stay alive before being summarily rolled back?
>>
>> That sounds very dangerous to me. You could end up breaking global
>> atomicity if some other resource in the global transaction committed.
> Right. You wouldn't enable it lightly..
> If pg_prepared_xacts had a time-of-preparation column, it would be
> possible to put the timeout policy in an external client. Perhaps that's
> a better solution?
This seems like a good idea to me in any case --- barring objections,
I will add this to the data structures and view.
regards, tom lane