From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Graham Vickrage" <graham(at)digitalplanit(dot)com> |
Cc: | "Postgres SQL" <pgsql-sql(at)postgresql(dot)org> |
Subject: | Re: Strategy for unlocking query |
Date: | 2001-04-04 16:07:17 |
Message-ID: | 10900.986400437@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
"Graham Vickrage" <graham(at)digitalplanit(dot)com> writes:
> I have just done a rather large transaction via a telnet/psql session which
> executed OK. The problem occured when the telnet session timed out before I
> could commit the rows.
> This must have locked the rows in question because when I tried to vacuum
> the table it just hung.
Probably the backend process was still there and didn't yet realize that
the client connection had died. It would notice eventually, but I think
the timeout involved is typically an hour or so (this is determined by
the TCP protocols and isn't under our control).
> What is the best way of dealing with this problem as I ended up stopping and
> restarting the postmaster?
It would've been sufficient to find and SIGTERM the individual backend
from the lost session.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-04-04 16:36:53 | Re: Historical dates in Timestamp |
Previous Message | Tom Lane | 2001-04-04 15:54:22 | Re: Query broken under 7.1RC2 |