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

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

From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
To: tgl(at)sss(dot)pgh(dot)pa(dot)us (Tom Lane)
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] It sorta works, but I'm confused about locking
Date: 1998-10-01 21:29:42
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
> I've got this new notify code almost working, but...
> 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.

Welcome to PostgreSQL.  This is the type of thing I saw when doing the
mega-patch, were people were not doing things consistently, because some
coders do not understand what is happening inside the code, and just
write something that works, sort of.

I recommend you check out what is currently done properly, and fix the
ones that are incorrect.

I can imagine some cases where you would want to get a lock and keep it
until the end of the transaction, and other times when you would want to
release it before transaction end.

> 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...

Select certainly should be locking.  Something is wrong, but I am not
sure what.  If you want me to check into it, let me know.

  Bruce Momjian                        |
  maillist(at)candle(dot)pha(dot)pa(dot)us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 1998-10-01 21:38:46
Subject: Re: [HACKERS] Proper cleanup at backend exit
Previous:From: Matthew C. AycockDate: 1998-10-01 19:01:24
Subject: Re: [HACKERS] pg_dump

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