From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] It sorta works, but I'm confused about locking |
Date: | 1998-10-02 00:25:15 |
Message-ID: | 29210.907287915@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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 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.
>> 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.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 1998-10-02 00:29:17 | Re: [HACKERS] Proper cleanup at backend exit |
Previous Message | Taral | 1998-10-01 23:45:33 | Re: [GENERAL] Long update query ? (also Re: [GENERAL] CNF vs. DNF) |