Stephan Szabo wrote:
On Tue, 11 Nov 2003, pginfo wrote:
It is possible to be one not closed transaction, but in this case nobody will
be
able to modify this table (tables) and
the system will stop to respond. The paradox is that the system works well
without
Not
Guys, does anyone has any idea?
pginfo wrote:
Hi,
I try to reindex and reindex run ok, but the vacuum still not running.
regards,
ivan.
Antonis Antoniou wrote:
pginfo wrote:
Hi,
I am running pg 7.3.4 on linux red hat 9.0.
If I try to execute vacuum full
On Tue, 11 Nov 2003, Antonis Antoniou wrote:
Guys, does anyone has any idea?
Are you sure that vacuum is not just waiting on a lock that some other
transaction is holding? I'd suggest checking the contents of pg_locks.
---(end of broadcast)---
Hi,
I can not be sure if it is not the case.
But we are usin this system on a number of servers and it happen only by
one.
Can I with a pg_locks help detect the query that is running?
regards,
ivan.
Stephan Szabo wrote:
On Tue, 11 Nov 2003, Antonis Antoniou wrote:
Guys, does anyone has any
pginfo wrote:
Hi,
I can not be sure if it is not the case.
But we are usin this system on a number of servers and it happen only by
one.
Can I with a pg_locks help detect the query that is running?
No the pg_locks detect only which process handle a lock on a
database object.
With pg_stat_activity
On Tue, 11 Nov 2003, pginfo wrote:
Hi,
I can not be sure if it is not the case.
But we are usin this system on a number of servers and it happen only by
one.
Can I with a pg_locks help detect the query that is running?
It won't directly tell you what statement is running (although my guess
Hi,
Thanks for the help.
The result by is:
acc01=# select * from pg_locks;
relation | database | transaction | pid | mode | granted
--+--+-+---+-+-
16757 |16976 | | 23169 | AccessShareLock | t
17062 |
On Tue, 11 Nov 2003, pginfo wrote:
The result by is:
acc01=# select * from pg_locks;
relation | database | transaction | pid | mode | granted
--+--+-+---+-+-
16757 |16976 | | 23169 | AccessShareLock | t
Hi,
Stephan Szabo wrote:
On Tue, 11 Nov 2003, pginfo wrote:
The result by is:
acc01=# select * from pg_locks;
relation | database | transaction | pid | mode | granted
--+--+-+---+-+-
16757 |16976 |
On Tue, 11 Nov 2003, pginfo wrote:
Stephan Szabo wrote:
On Tue, 11 Nov 2003, pginfo wrote:
The result by is:
acc01=# select * from pg_locks;
relation | database | transaction | pid | mode | granted
Stephan Szabo wrote:
On Tue, 11 Nov 2003, pginfo wrote:
Stephan Szabo wrote:
On Tue, 11 Nov 2003, pginfo wrote:
The result by is:
acc01=# select * from pg_locks;
relation | database | transaction | pid | mode | granted
On Tue, 11 Nov 2003, pginfo wrote:
It is possible to be one not closed transaction, but in this case nobody will be
able to modify this table (tables) and
the system will stop to respond. The paradox is that the system works well
without
Not necessarily. People are going to be
pginfo wrote:
Hi,
I am running pg 7.3.4 on linux red hat 9.0.
If I try to execute vacuum full analyze verbose, the pg vacuum some
tables and hang after this lines:
INFO: --Relation pg_toast.pg_toast_16408--
INFO: Pages 0: Changed 0, reaped 0, Empty 0, New 0; Tup 0: Vac 0,
Keep/VTL 0/0, UnUsed
Hi,
I try to reindex and reindex run ok, but the vacuum still not running.
regards,
ivan.
Antonis Antoniou wrote:
pginfo wrote:
Hi,
I am running pg 7.3.4 on linux red hat 9.0.
If I try to execute vacuum full analyze verbose, the pg vacuum some
tables and hang after this lines:
INFO:
Hi,
I am running pg 7.3.4 on linux red hat 9.0.
If I try to execute vacuum full analyze verbose, the pg vacuum some
tables and hang after this lines:
INFO: --Relation pg_toast.pg_toast_16408--
INFO: Pages 0: Changed 0, reaped 0, Empty 0, New 0; Tup 0: Vac 0,
Keep/VTL 0/0, UnUsed 0, MinLen 0,
15 matches
Mail list logo
