Greetings:

I am working on converting a transportation application from a Progress
database to PostgreSQL. This application will be hammered by about 75 users
at any given time. Also, depending on the operation, there are many record
updates that occur at the trigger level. I would like to be able to provide
feedback to the user when they select a row for update (using SELECT FOR
UPDATE). At present, if the row is being accessed (with SELECT FOR UPDATE) by
another user, the application just sits there waiting. I spent some time
looking at pg_locks hoping to be able to gain information from that table so
as to programically return something to the user. The stuff I read didn't
look promising. The only thing I've been able to come up with is having my
own "lock" table and inserting a row into it containing the table name, the
pid, the oid of the row, the user id, and a time stamp. Of course, I'm
searching lock table entries before selecting for update and reporting a lock
situation to the user if I find anything. I'm just wondering if I can use
some system table or combination of tables to provide the feed back I need.
Does anyone have any ideas about how to accomplish this? I searched the FAQ
and didn't find anything.

PostgreSQL 7.3.6-RH on i386-redhat-linux-gnu, compiled by GCC
i386-redhat-linux-gcc (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-39)

Thanks...
--
Quote: 32
"The world we have created is a product of our thinking. It cannot be
changed without changing our thinking."

--Albert Einstein

Work: 1-336-372-6812
Cell: 1-336-363-4719
email: terry (AT) esc1 (DOT) com

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Terry Lee Tucker <terry (AT) esc1 (DOT) com> writes:
To me, this says that you're already off on the wrong foot.

You don't ever want your client application holding locks while a
human user edits text, drinks coffee, goes out to lunch, or whatever.
A better design is to fetch the data without locking it, allow the
user to edit as he sees fit, and then when he clicks "save" you do
something like

begin;
select row for update;
if [ row has not changed since you originally pulled it ] then
update row with changed values;
commit;
else
abort;
notify user of conflicts
let user edit new data to resolve conflicts and try again
fi

In this design the row lock is only held for milliseconds.

You need to provide some code to let the user merge what he did with the
prior changes, so that he doesn't have to start over from scratch in the
failure case. What "merge" means requires some business-logic knowledge
so I can't help you there, but this way you are spending your effort on
something that actually helps the user, rather than just tells him he
has to wait. Performance will be much better too --- long-lasting
transactions are nasty for all sorts of reasons.

BTW, a handy proxy for "row has not changed" is to see if its XMIN
system column is still the same as before. If so, no transaction has
committed an update to it. (This may or may not help much, since you're
probably going to end up groveling over all the fields anyway in the
"notify user" part, but it's a cool hack if you can use it.)

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster