Re: [PATCH] V3: Idle in transaction cancellation
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Greg Smith <greg@2ndquadrant.com>, Andres Freund <andres@anarazel.de>, Alvaro Herrera <alvherre@commandprompt.com>, pgsql-hackers <pgsql-hackers@postgresql.org>, Kevin Grittner <kevin.grittner@wicourts.gov>
Date: 2010-12-16T20:49:38Z
Lists: pgsql-hackers
On Thu, Dec 16, 2010 at 3:41 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> I thought the next thing we'd report would be the recovery >> conflict, not any bizarre can't-abort-the-transaction scenario. > > Well, if we discard it because we're too lazy to implement error message > merging, that's OK. Presumably it'll still get into the postmaster log. OK, that's reasonable. >>> (Hm, but I wonder whether there are any hard >>> timing constraints in the ssl protocol ... although hopefully xact abort >>> won't ever take long enough that that's a real problem.) > >> That would be incredibly broken. > > Think "authentication timeout". I wouldn't be a bit surprised if the > remote end would drop the connection if certain events didn't come back > reasonably promptly. There might even be security reasons for that, > ie, somebody could brute-force a key if you give them long enough. > (But this is all speculation; I don't actually know SSL innards.) I would be really surprised if aborting a transaction takes long enough to mess up SSL. I mean, there could be a network delay at any time, too. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company