Re: [HACKERS] It sorta works, but I'm confused about locking - Mailing list pgsql-hackers

From Massimo Dal Zotto
Subject Re: [HACKERS] It sorta works, but I'm confused about locking
Date
Msg-id 199809281646.SAA01373@boogie.cs.unitn.it
Whole thread Raw
In response to It sorta works, but I'm confused about locking  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] It sorta works, but I'm confused about locking  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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@cs.unitn.it             |
|  Via Marconi, 141                 phone:  ++39-461-534251            |
|  38057 Pergine Valsugana (TN)     www:  http://www.cs.unitn.it/~dz/  |
|  Italy                            pgp:  finger dz@tango.cs.unitn.it  |
+----------------------------------------------------------------------+

pgsql-hackers by date:

Previous
From: Massimo Dal Zotto
Date:
Subject: Re: [HACKERS] Think we need major revisions in async.c...
Next
From: jwieck@debis.com (Jan Wieck)
Date:
Subject: Little parser question