do a "ps -ef | grep transact"
and look for "idle in transaction" postmaster processes.
If you're certain that nobody else is running that transaction (i.e. nobody on
the system or the process with the idle transaction has been sitting there
for a while and normally the application doesn't have long running
transactions) then just kill the process in question (don't kill -9 it!)
That will roll the transaction back and close it.
Hope that helps
Uwe
On Friday 20 October 2006 00:04, Naz Gassiep wrote:
> I was performing a bunch of INSERTs into a table, users, that has a
> unique index on username. During the transaction, my internet connection
> dropped. The INSERTs were being done inside a transaction.
>
> Once I had manhandled my DSL router back online, I went back into a
> console to redo the inserts. I found that after I did the first insert,
> it appeared to freeze. I thought that my net had dropped out again, but
> I was able to Ctrl+C the command and rollback and do it again, with the
> same result. The previous connection is obviously still active, locking
> the transaction until the fate of the previous insert with that username
> is known, i.e., the ghost connection rolls back or commits.
>
> How do I determine which connection is the ghost connection, and how do
> I tell PG to kill it? Also, is it an OS setting to determine the timeout
> on open but inactive connections, or a PG setting?
>
> - Naz.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
--
UC
--
Open Source Solutions 4U, LLC 1618 Kelly St
Phone: +1 707 568 3056 Santa Rosa, CA 95401
Cell: +1 650 302 2405 United States
Fax: +1 707 568 6416