Re: SELECT FOR UPDATE

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.