Re: transaction idle timeout in 7.4.5 and 8.0.0beta2
От | Tom Lane |
---|---|
Тема | Re: transaction idle timeout in 7.4.5 and 8.0.0beta2 |
Дата | |
Msg-id | 5865.1095532352@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: transaction idle timeout in 7.4.5 and 8.0.0beta2 ("Jeroen T. Vermeulen" <jtv@xs4all.nl>) |
Ответы |
Re: transaction idle timeout in 7.4.5 and 8.0.0beta2
Re: transaction idle timeout in 7.4.5 and 8.0.0beta2 |
Список | pgsql-hackers |
"Jeroen T. Vermeulen" <jtv@xs4all.nl> writes: > On Sat, Sep 18, 2004 at 12:43:05PM -0400, Tom Lane wrote: >> I don't see any reason for guesswork. Remember the PID of the backend >> you were connected to. On reconnect, look in pg_stat_activity to see if >> that backend is still alive; if so, sleep till it's not. > Looks like that only works if stats_command_string is set (and backend > version is at least 7.2), correct? No, stats_command_string need not be set, only stats_start_collector. > I couldn't find this table in the > online documentation, http://www.postgresql.org/docs/7.4/static/monitoring-stats.html#MONITORING-STATS-VIEWS-TABLE > but can I assume that the query will have finished > executing (whether for good or for bad) when its current_query is either > empty or null? No, because of the reporting delay. I would recommend waiting for the backend's row in pg_stat_activity to disappear entirely. Under normal circumstances that should occur quickly. If there's a communications problem, it might take awhile to detect connection loss ... but if there's a communications problem, you probably aren't going to be able to open a new connection, either. regards, tom lane
В списке pgsql-hackers по дате отправления: