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  ("Jeroen T. Vermeulen" <jtv@xs4all.nl>)
Re: transaction idle timeout in 7.4.5 and 8.0.0beta2  ("Jeroen T. Vermeulen" <jtv@xs4all.nl>)
Список 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 по дате отправления:

Предыдущее
От: David Wheeler
Дата:
Сообщение: Re: libpq and prepared statements progress for 8.0
Следующее
От: "Jeroen T. Vermeulen"
Дата:
Сообщение: Re: transaction idle timeout in 7.4.5 and 8.0.0beta2