On Tue, Jun 24, 2014 at 10:50 AM, Vik Fearing <vik.fear...@dalibo.com> wrote: > On 06/24/2014 04:04 PM, Robert Haas wrote: >>> If the local transaction is actually idle in transaction and the local >>> > server doesn't have a timeout, we're no worse off than before this patch. >> >> I think we are. First, the correct timeout is a matter of >> remote-server-policy, not local-server-policy. If the remote server >> wants to boot people with long-running idle transactions, it's >> entitled to do that, and postgres_fdw shouldn't assume that it's >> "special". > > So how would the local transaction ever get its work done? What option > does it have to tell the remote server that it isn't actually idling, it > just doesn't need to use the remote connection for a while?
It *is* idling. You're going to get bloat, and lock contention, and so on, just as you would for any other idle session. I mean, you could make this assumption about any session: I'm not done with the transaction yet, e.g. I'm waiting for user input before deciding what to do next. That doesn't mean that the DBA doesn't want to kill it. > The point of the patch is to allow the DBA to knock off broken clients, > but this isn't a broken client, it just looks like one. If it walks like a duck, and quacks like a duck, it's a duck. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
