From: | will trillich <will(at)serensoft(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | question about locking (and documentation thereof) |
Date: | 2002-01-10 23:01:30 |
Message-ID: | 20020110170130.A28740@serensoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
in the docs regarding locking paradigms, this part makes sense to me:
Take a SHARE ROW EXCLUSIVE lock on a primary key table when going to
perform a delete operation:
BEGIN WORK;
LOCK TABLE films IN SHARE ROW EXCLUSIVE MODE;
DELETE FROM films_user_comments WHERE id IN
(SELECT id FROM films WHERE rating < 5);
DELETE FROM films WHERE rating < 5;
COMMIT WORK;
no problem -- lock the table, delete from subsidiary table, then purge
previously referred-to records in the master (locked) table.
but just above that example, there's this:
BEGIN WORK;
LOCK TABLE films IN SHARE MODE;
SELECT id FROM films
WHERE name = 'Star Wars: Episode I - The Phantom Menace';
-- Do ROLLBACK if record was not returned
INSERT INTO films_user_comments VALUES
(_id_, 'GREAT! I was waiting for it for so long!');
COMMIT WORK;
"select id"? where does it go to? can any selected field be later
referred to as _fieldname_ somehow? i've not yet found that in
the docs anywhere...
i was looking for how to take advantage of 'select for update'
and this ran across my radar. what's up?
--
DEBIAN NEWBIE TIP #104 from Sean Quinlan <smq(at)gmx(dot)co(dot)uk>
:
Looking to CUSTOMIZE THE COLORS USED BY LS? I find its easier
to run "dircolors -p >~/.dircolors" and then add "eval
`dircolors -b ~/.dircolors`" to my .bashrc and then make all
changes to ~/.dircolors (instead of the system-wide
/etc/DIR_COLORS). Probably more pertinent on a multi user
system, but good policy nevertheless.
Also see http://newbieDoc.sourceForge.net/ ...
From | Date | Subject | |
---|---|---|---|
Next Message | Mike Schroepfer | 2002-01-10 23:59:38 | Re: Insert Performance with WAL and Fsync |
Previous Message | Doug McNaught | 2002-01-10 22:26:39 | Re: duplicating tables (accross databases) |