I have a situation regarding locks that nobody seems to own:

using psql:

Chipoteka=3D> select pg_class.relname,pg_locks.* from pg_class,pg_locks=20
where pg_class.relfilenode=3Dpg_locks.relation;
relname | locktype | database | relation | page | tuple |=20
transactionid | classid | objid | objsubid | transaction | pid |=20=20=20=
=20=20=20
mode | granted
--------------+----------+----------+----------+------+-------+------------=
---+---------+-------+----------+-------------+------+-----------------+---=
------
valuta | relation | 366513 | 366657 | |=20=20=20=20=20=20=
=20
jezik | relation | 366513 | 366567 | |=20=20=20=20=20=20=
=20
jezik | relation | 366513 | 366567 | |=20=20=20=20=20=20=
=20
serverconfig | relation | 366513 | 375491 | |=20=20=20=20=20=20=
=20
mjesto | relation | 366513 | 366584 | |=20=20=20=20=20=20=
=20
drzava | relation | 366513 | 366550 | |=20=20=20=20=20=20=
=20
orgjed | relation | 366513 | 366596 | |=20=20=20=20=20=20=
=20
serverconfig | relation | 366513 | 375491 | |=20=20=20=20=20=20=
=20
serverconfig | relation | 366513 | 375491 | |=20=20=20=20=20=20=
=20
drzava | relation | 366513 | 366550 | |=20=20=20=20=20=20=
=20
valuta | relation | 366513 | 366657 | |=20=20=20=20=20=20=
=20
jezik | relation | 366513 | 366567 | |=20=20=20=20=20=20=
=20
valuta | relation | 366513 | 366657 | |=20=20=20=20=20=20=
=20
pg_class | relation | 366513 | 1259 | |=20=20=20=20=20=20=
=20
orgjed | relation | 366513 | 366596 | |=20=20=20=20=20=20=
=20
pg_locks | relation | 366513 | 10342 | |=20=20=20=20=20=20=
=20
drzava | relation | 366513 | 366550 | |=20=20=20=20=20=20=
=20
mjesto | relation | 366513 | 366584 | |=20=20=20=20=20=20=
=20
orgjed | relation | 366513 | 366596 | |=20=20=20=20=20=20=
=20
mjesto | relation | 366513 | 366584 | |=20=20=20=20=20=20=
=20
(20 rows)

from the shell:

kresot@kreso:~$ ps auxw|grep post
postgres 1388 0.0 0.4 151980 6304 ? S 09:16 0:00=20
/usr/lib/postgresql/8.1/bin/postmaster -D /var/lib/postgresql/8.1/main=20
-c unix_socket_directory=3D/var/run/postgresql -c=20
config_file=3D/etc/postgresql/8.1/main/postgresql.conf -c=20
hba_file=3D/etc/postgresql/8.1/main/pg_hba.conf -c=20
ident_file=3D/etc/postgresql/8.1/main/pg_ident.conf -c=20
external_pid_file=3D/var/run/postgresql/8.1-main.pid
postgres 1390 0.0 5.7 152128 89944 ? S 09:16 0:00=20
postgres: writer process=20=20
postgres 1391 0.0 0.1 10728 1884 ? S 09:16 0:00=20
postgres: stats buffer process=20=20
postgres 1392 0.0 0.0 10016 1424 ? S 09:16 0:00=20
postgres: stats collector process=20=20
kresot 5699 0.0 0.0 3224 636 pts/0 S+ 11:11 0:00 grep post

The situation is the same after I restart postgres.

My environment: postgres 8.1.4 on debian.

Is this a bug, or am I doing something wrong?

--=20
Kre=C5=A1imir Tonkovi=C4=87
Z-el d.o.o.
Industrijska cesta 28, 10360 Sesvete, Croatia
Tel: +385 1 2022 758
Fax: +385 1 2022 741
Web: www.chipoteka.hr
e-mail: z-el.tonkovic (AT) chipoteka (DOT) hr




---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Kresimir Tonkovic wrote:
--------=20

This is a problem for me because I'm trying to drop this database, but=20
dropdb complains about other users using it. I suppose these locks are=20
what prevent dropdb from doing it's work.

Best regards,

--=20
Kre=C5=A1imir Tonkovi=C4=87
Z-el d.o.o.
Industrijska cesta 28, 10360 Sesvete, Croatia
Tel: +385 1 2022 758
Fax: +385 1 2022 741
Web: www.chipoteka.hr
e-mail: z-el.tonkovic (AT) chipoteka (DOT) hr




---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Kresimir Tonkovic <z-el.tonkovic (AT) chipoteka (DOT) hr> writes:
The only way pid can be null in a pg_locks entry is if the lock is held
by a prepared transaction. See pg_prepared_xacts view.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings