Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] It sorta works, but I'm confused about locking

From: Massimo Dal Zotto <dz(at)cs(dot)unitn(dot)it>
To: hackers(at)postgreSQL(dot)org (PostgreSQL Hackers)
Cc: tgl(at)sss(dot)pgh(dot)pa(dot)us (Tom Lane)
Subject: Re: [HACKERS] It sorta works, but I'm confused about locking
Date: 1998-09-28 16:46:58
Message-ID: 199809281646.SAA01373@boogie.cs.unitn.it (view raw or flat)
Thread:
Lists: pgsql-hackers
> 
> I've got this new notify code almost working, but...

Could you plase send it to me ?

> What exactly is the protocol for locking a table that you intend to
> modify?  The old notify code just did RelationSetLockForWrite(),
> but it's not clear to me that that works correctly --- for one thing,
> it doesn't seem to offer any way of detecting failure to acquire the
> lock.  (RelationSetLockForWrite calls MultiLockReln, which *does*
> return a boolean, but RelationSetLockForWrite ignores it...)  Also,
> it's not at all clear whether I should call RelationUnsetLockForWrite
> at the end of the routine or not; some existing code does, some doesn't.

It is not done where there is an immediate CommitTransactionCommand which
already releases the locks.

> I'm concerned because interlocking of the specialized NOTIFY-related
> statements seems to work fine, but they seem not to be interlocked
> against user operations on the pg_listener table.
> 
> For example, this works as I'd expect:
> 
> 	psql#1				psql#2
> 
> 	begin;
> 	listen z;
> 
> 					notify z;
> 					(hangs up until #1 commits)
> 
> 	end;
> 
> because "listen" acquires a write lock on the pg_listener table, which
> the notify has to wait for.
> 
> But this doesn't work as I'd expect:
> 
> 	psql#1				psql#2
> 
> 	begin;
> 	select * from pg_listener;
> 
> 					notify z;
> 					(completes immediately)
> 
> 	end;
> 
> Seems to me the "select" should acquire a read lock that would prevent
> the #2 backend from writing pg_listener until the end of #1's transaction.
> 
> Is there a bug here, or is there some special definition of user access
> to a system table that means the select isn't acquiring a read lock?
> Selects and updates on ordinary user tables seem to interlock fine...

Very strange, it seems a bug. But users should not know about pg_listener.

-- 
Massimo Dal Zotto

+----------------------------------------------------------------------+
|  Massimo Dal Zotto                email:  dz(at)cs(dot)unitn(dot)it             |
|  Via Marconi, 141                 phone:  ++39-461-534251            |
|  38057 Pergine Valsugana (TN)     www:  http://www.cs.unitn.it/~dz/  |
|  Italy                            pgp:  finger dz(at)tango(dot)cs(dot)unitn(dot)it  |
+----------------------------------------------------------------------+

In response to

pgsql-hackers by date

Next:From: Jan WieckDate: 1998-09-28 16:56:39
Subject: Little parser question
Previous:From: Massimo Dal ZottoDate: 1998-09-28 16:39:47
Subject: Re: [HACKERS] Think we need major revisions in async.c...

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group