Francisco Reyes wrote:
Chris writes:
Is there a way to tell what tables have locks on them?
SELECT * from pg_locks ;
(version 7.4 and above at least, don't have an install earlier than
that).
And this is per DB right?
No, this is per system.
Not sure how it works with permissions (eg i
Chris writes:
Is there a way to tell what tables have locks on them?
SELECT * from pg_locks ;
(version 7.4 and above at least, don't have an install earlier than that).
And this is per DB right?
Any way to tell locks in all DBs?
In particular if planning to bounce back the DB would be nice
Francisco Reyes wrote:
Tom Lane writes:
CREATE INDEX shouldn't block any concurrent SELECT, regardless of which
index AM is involved.
The problem was that the table needed a "vacuum full". It was a large
table and had done a massive update. It is not that it was blocked, but
that it was jus
Tom Lane writes:
CREATE INDEX shouldn't block any concurrent SELECT, regardless of which
index AM is involved.
The problem was that the table needed a "vacuum full". It was a large table
and had done a massive update. It is not that it was blocked, but that it
was just taking a very long tim
Francisco Reyes <[EMAIL PROTECTED]> writes:
> As I write this I am creating an index with gist and trying to do a select
> on the table froze. Using Postgresql 8.1.3
CREATE INDEX shouldn't block any concurrent SELECT, regardless of which
index AM is involved. Can you provide a reproducible test
The release notes for 8.1, http://www.postgresql.org/docs/whatsnew, states
about GIST
indexing mechanism has improved to support the high-speed concurrency,
recoverability and update performance
As I write this I am creating an index with gist and trying to do a select
on the table froze. Us
