Phoenix Kiula writes:
> I guess my question is, how should I remove all pending locks on a
> table so that I can get on with the rest of the stuff?
>
> I mean, even if I can now find an offending RULE on the table, I
> cannot replace or remove it. '
You're off on the wrong track. Locks are held
phoenix.ki...@gmail.com (Phoenix Kiula) writes:
> On Wed, Mar 4, 2009 at 12:55 AM, Phoenix Kiula
> wrote:
>> I guess my question is, how should I remove all pending locks on a
>> table so that I can get on with the rest of the stuff?
>>
>> I mean, even if I can now find an offending RULE on the t
On Wed, Mar 4, 2009 at 1:23 AM, Phoenix Kiula wrote:
> On Wed, Mar 4, 2009 at 1:17 AM, Tom Lane wrote:
>> Phoenix Kiula writes:
>>> How can I get rid of these open locks?
>>
>> Close the transactions that are holding them. Look into
>> pg_stat_activity and pg_prepared_xacts.
>
>
> Thanks for th
On Wed, Mar 4, 2009 at 1:17 AM, Tom Lane wrote:
> Phoenix Kiula writes:
>> How can I get rid of these open locks?
>
> Close the transactions that are holding them. Look into
> pg_stat_activity and pg_prepared_xacts.
Thanks for this. But can I simply delete all the pg_locks table? Or
delete all
On Wed, Mar 4, 2009 at 12:55 AM, Phoenix Kiula wrote:
> I guess my question is, how should I remove all pending locks on a
> table so that I can get on with the rest of the stuff?
>
> I mean, even if I can now find an offending RULE on the table, I
> cannot replace or remove it. '
Any ideas? I
Phoenix Kiula writes:
> How can I get rid of these open locks?
Close the transactions that are holding them. Look into
pg_stat_activity and pg_prepared_xacts.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to you
I guess my question is, how should I remove all pending locks on a
table so that I can get on with the rest of the stuff?
I mean, even if I can now find an offending RULE on the table, I
cannot replace or remove it. '
Thanks for any pointers!
--
Sent via pgsql-general mailing list (pgsql-genera
- "Phoenix Kiula" wrote:
> On Wed, Mar 4, 2009 at 12:36 AM, Adrian Klaver
> wrote:
> >
> > Are you connected to the right database?. I have been in that
> situation, looking at the log for db A and doing things in db B.
>
>
> Thanks. I only have one database, so yes I am connected to it.
On Wed, Mar 4, 2009 at 12:36 AM, Adrian Klaver wrote:
>
> Are you connected to the right database?. I have been in that situation,
> looking at the log for db A and doing things in db B.
Thanks. I only have one database, so yes I am connected to it.
I have the lock file in /tmp:.s.PGSQL.54
- "Phoenix Kiula" wrote:
> > commit the transaction where you altered the table. It has an open
> lock on
> > the table.
>
>
>
> =# commit;
>
> WARNING: there is no transaction in progress
> COMMIT
> Time: 0.282 ms
>
>
> So no, there's nothing pending.
>
> --
Are you connected to t
Although when I try this:
select pg_class.relname,pg_locks.* from pg_class,pg_locks where
pg_class.relfilenode=pg_locks.relation;
There are many rows!
How can I get rid of these open locks?
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscripti
> commit the transaction where you altered the table. It has an open lock on
> the table.
=# commit;
WARNING: there is no transaction in progress
COMMIT
Time: 0.282 ms
So no, there's nothing pending.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to y
On Wed, Mar 4, 2009 at 12:10 AM, Tom Lane wrote:
> Phoenix Kiula writes:
>> Now when I do:
>> vacuum analyze TABLENAME
>> or
>> delete from TABLENAME where id = 99
>> Nothing happens! The carriage return means the my shell cursor goes to
>> the next line, but it just stays there.
>
> Did you
On Tuesday 03 March 2009, Phoenix Kiula wrote:
> HI. I made a small alteration to a table (added a column).
>
> Now when I do:
>
> vacuum analyze TABLENAME
>
> or
>
> delete from TABLENAME where id = 99
>
> Nothing happens! The carriage return means the my shell cursor goes to
> the next line,
Phoenix Kiula writes:
> Now when I do:
> vacuum analyze TABLENAME
> or
> delete from TABLENAME where id = 99
> Nothing happens! The carriage return means the my shell cursor goes to
> the next line, but it just stays there.
Did you forget the semicolon?
regards, tom l
15 matches
Mail list logo