"Jeroen T. Vermeulen" <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
