Re: [PATCH] V3: Idle in transaction cancellation
От | Robert Haas |
---|---|
Тема | Re: [PATCH] V3: Idle in transaction cancellation |
Дата | |
Msg-id | AANLkTinB9pbH1A5Cy06VL9z16k3vNgpXgC8r5301=0e9@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PATCH] V3: Idle in transaction cancellation (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [PATCH] V3: Idle in transaction cancellation
|
Список | 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
В списке pgsql-hackers по дате отправления: