Re: Request: pg_cancel_backend variant that handles 'idle in transaction' sessions
От | Jim Nasby |
---|---|
Тема | Re: Request: pg_cancel_backend variant that handles 'idle in transaction' sessions |
Дата | |
Msg-id | 563D64B8.6080909@BlueTreble.com обсуждение исходный текст |
Ответ на | Re: Request: pg_cancel_backend variant that handles 'idle in transaction' sessions (Merlin Moncure <mmoncure@gmail.com>) |
Список | pgsql-hackers |
On 11/3/15 8:44 AM, Merlin Moncure wrote: >> Actually, one other thing that would help is to have the ability to turn >> >this into an ERROR: >> > >> >begin; >> >WARNING: there is already a transaction in progress > curious: does the SQL standard define this behavior? > > Anyways, we've pretty studiously avoided (minus a couple of > anachronisms) .conf setting thats control behavior of SQL commands in > a non performance way. If we had an event trigger on BEGIN and a way to tell whether we were already in a transaction this wouldn't need to be a config setting. > IMO, this as yet another case for 'stored procedures' that can manage > transaction state: you could rig up your own procedure: CALL > begin_tx_safe(); which would test transaction state and fail if > already in one. This doesn't help you if you're not in direct control > of application generated SQL but it's a start. Barring that, at least Even then it would be very easy to mess this up. > warnings tend to stand out in the database log. That depends greatly on how much other stuff is in the log. Something else I wish we had was the ability to send different log output to different places. -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com
В списке pgsql-hackers по дате отправления: