Thread: Cancelled Vacuum Leaving Tables Locked?

I am running postgresql-7.1.3-1PGDG on RedHat Linux 6.2

If I start a "VACUUM ANALYZE" and later hit Ctrl-C to
stop it, the table that was in mid-vacuum seems to
say locked.  Any opperation on the table after that point
takes far longer than I am willing to wait.  A clean
restart fixes the problem.

Is this a bug?  Ideas?

Orion Henry <orion@trustcommerce.com> writes:
> I am running postgresql-7.1.3-1PGDG on RedHat Linux 6.2
> If I start a "VACUUM ANALYZE" and later hit Ctrl-C to
> stop it, the table that was in mid-vacuum seems to
> say locked.

?? I can't replicate this, and I don't recall ever hearing a similar
complaint from anyone else.  There's got to be some additional factor
in your situation.

            regards, tom lane

I think I've seen this, or something similar...when I was doing a CREATE
INDEX on a huge table and cancelled it, but there was still a postmaster
process running on the server doing CREATE, and the table was still locked.
I did everything short of 'kill -9' to the process, and it ignored me....I
checked back several hours later and it was gone...probably finished with
the CREATE and exited.

Incidentally, can someone tell me what happens when you do a CREATE INDEX or
a VACUUM ANALYZE?  It seems like it should be a O(n) type operation, yet it
seems to take an excessively increasing long time as table size grows, like
O(n^2) or something...

pgsql-general@postgresql.org <pgsql-general@postgresql.org>
----- Original Message -----
From: "Tom Lane" <tgl@sss.pgh.pa.us>
To: "Orion Henry" <orion@trustcommerce.com>
Cc: <pgsql-general@postgresql.org>
Sent: Wednesday, November 28, 2001 10:09 AM
Subject: Re: [GENERAL] Cancelled Vacuum Leaving Tables Locked?


> Orion Henry <orion@trustcommerce.com> writes:
> > I am running postgresql-7.1.3-1PGDG on RedHat Linux 6.2
> > If I start a "VACUUM ANALYZE" and later hit Ctrl-C to
> > stop it, the table that was in mid-vacuum seems to
> > say locked.
>
> ?? I can't replicate this, and I don't recall ever hearing a similar
> complaint from anyone else.  There's got to be some additional factor
> in your situation.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>
>