Re: Request: pg_cancel_backend variant that handles 'idle in transaction' sessions
От | David Steele |
---|---|
Тема | Re: Request: pg_cancel_backend variant that handles 'idle in transaction' sessions |
Дата | |
Msg-id | 563BBBD5.1060207@pgmasters.net обсуждение исходный текст |
Ответ на | Re: Request: pg_cancel_backend variant that handles 'idle in transaction' sessions (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Список | pgsql-hackers |
On 11/5/15 10:10 AM, Alvaro Herrera wrote: > David Steele wrote: > >> The important thing about this implementation was that nothing was >> terminated unless it had exceed a timeout AND was blocking another >> process. > > This seems a nice idea, but you need to take the effect on vacuum of > idle-in-xact sessions too. If the operator left for the day and their > session doesn't block any other process, the next day you could find > some tables bloated to such extreme as to cause problems later on. > Surely the operator can review their terminal to re-do the work, in case > it was valuable. (If it was valuable, why didn't they commit the > transaction?) These particular databases were not subject to bloat since they were partitioned and append-only - no inserts or deletes whatsoever except to tiny dimension tables. In general, though, you are correct. An absolute transaction timeout would be a good first step but a blocking timeout would also be very handy. It would be very applicable to data warehouse scenarios where bloat is controlled by other means and long transactions are the norm (and idle-in-transactions times can also be long). -- -David david@pgmasters.net
В списке pgsql-hackers по дате отправления: