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-02 02:24:20
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
> Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> writes:
> > I recommend you check out what is currently done properly, and fix the
> > ones that are incorrect.
> Well, yes.  The question was how to tell which is which :-)

I didn't say it was easy.  :-)

> > 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 guess I'm not understanding something.  How can it ever be correct
> practice to release a lock before transaction end?  For example, if I
> write some changes in a table, and then release the lock, wouldn't that
> allow other backends to see the not-yet-committed changes?  What if I
> then abort my transaction?  Now the other backends have acted on
> information they should never have seen at all.
> Releasing a read lock strikes me as just as dangerous but for more
> subtle reasons --- once you have read a table, what you have read
> ought to look the same until the end of your transaction.
> Since there is an unset-write-lock function, I assume it must have
> valid uses, but I don't see what they are.

Suppose you want to update a table as part of internal query processing.
You lock it, update it, and unlock it.  You just need the lock while
you are updating it.

> >> 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.
> Please.  (Note that I saw this with my revised version of async.c;
> I believe you will see the same behavior with the currently-checked-in
> code, but do not have the time to rebuild that version to make sure.)

  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-02 02:25:23
Subject: Re: [HACKERS] Proper cleanup at backend exit
Previous:From: Bruce MomjianDate: 1998-10-02 02:18:29
Subject: Re: [GENERAL] Long update query ? (also Re: [GENERAL] CNF vs. DNF)

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