Robert Creager <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> confessed:
>> so indeed everyone is waiting for this process:
>>
>> postgres 29304 20209 0 17:37 pts/400:00:00 postgres: robert tassiv
>> 192.168.0.250 idle in transaction
> Hmmm... Not sure what t
When grilled further on (Sun, 05 Oct 2003 23:22:45 -0400),
Tom Lane <[EMAIL PROTECTED]> confessed:
>
> so indeed everyone is waiting for this process:
>
> postgres 29304 20209 0 17:37 pts/400:00:00 postgres: robert tassiv
> 192.168.0.250 idle in transaction
Hmmm... Not
Robert Creager <[EMAIL PROTECTED]> writes:
> tassiv=# select relname, pg_locks.* from pg_locks left join pg_class on (
> pg_locks.relation = pg_class.oid );
Okay, let's chase it back. The VACUUM (pid 29549) is blocked trying to
lock temp_obs_i for vacuuming:
> temp_obs_i| 50033625 | 500
When grilled further on (Sun, 05 Oct 2003 20:34:15 -0400),
Tom Lane <[EMAIL PROTECTED]> confessed:
>
> Almost certainly, that guy is holding the lock REINDEX wants. The
> VACUUM is probably backed up behind the REINDEX. If you want to
> convince me it's a deadlock, you'll need to exhibit pg_loc
Robert Creager <[EMAIL PROTECTED]> writes:
> postgres 29304 20209 0 17:37 pts/400:00:00 postgres: robert tassiv
> 192.168.0.250 idle in transaction
Almost certainly, that guy is holding the lock REINDEX wants. The
VACUUM is probably backed up behind the REINDEX. If you
I'm running 7.4b4 and ran into a little problem with my import and pg_autovacuum's
call of VACUUM.
PostgreSQL 7.4beta4 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.2.2 (Mandrake
Linux 9.1 3.2.2-3mdk)
$ ./configure --with-tcl --with-openssl=/usr/include/openssl --with-CXX
--enable-syslog
