| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Jeroen T(dot) Vermeulen" <jtv(at)xs4all(dot)nl> |
| Cc: | Szima G?bor <sygma(at)axelero(dot)hu>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: transaction idle timeout in 7.4.5 and 8.0.0beta2 |
| Date: | 2004-09-18 18:32:32 |
| Message-ID: | 5865.1095532352@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"Jeroen T. Vermeulen" <jtv(at)xs4all(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeroen T. Vermeulen | 2004-09-18 18:46:01 | Re: transaction idle timeout in 7.4.5 and 8.0.0beta2 |
| Previous Message | David Wheeler | 2004-09-18 17:28:54 | Re: libpq and prepared statements progress for 8.0 |