Re: SELECT FOR UPDATE - Mailing list pgsql-general

From ok@mochamail.com (Cody)
Subject Re: SELECT FOR UPDATE
Date
Msg-id b7be5f20.0108261250.283023a6@posting.google.com
Whole thread Raw
In response to Re: SELECT FOR UPDATE  (Jan Wieck <JanWieck@Yahoo.com>)
List pgsql-general
I just finished reading Bruce M's book, so this thread confuses me,
esp. Jan's posts.  I take full heed of the need for application level
user/thread management, but I was interested in using a parallel
set-up in PG (however redundant that might be).  Now that Jan has
discounted "SELECT...FOR UPDATE," is the best alternative using a
central locking table (perhaps in conjunction with LISTEN & NOTIFY)?
Ironically, anyone who suggested using application level transactions
would be torn apart at any of the places I've worked at--but that
seems to be the gist of this thread.  I cannot see a way to avoid
deadlocks without an application level transaction component, since
the central locking table idea would similarily lock the record
forever if the first transaction failed to COMMIT or ROLLBACK.

What is the saying:  To the beginner, there are many options.  To the
wise, there are few.

pgsql-general by date:

Previous
From: Jacek Lampart
Date:
Subject: Wanted: Postgres 6.5.3 dll
Next
From: "satish rao "
Date:
Subject: Create table syntax