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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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 |
+----------------------------------------------------------------------+
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Wieck | 1998-09-28 16:56:39 | Little parser question |
Previous Message | Massimo Dal Zotto | 1998-09-28 16:39:47 | Re: [HACKERS] Think we need major revisions in async.c... |