Re: libpq program SELECT FOR UPDATE and TIMEOUT or CANCEL REQUEST

From: Bruno Wolff III <bruno(at)wolff(dot)to>
To: Jeff Pogodzinski <jrpogo(at)yahoo(dot)com>
Cc: pgsql-sql(at)postgresql(dot)org
Subject: Re: libpq program SELECT FOR UPDATE and TIMEOUT or CANCEL REQUEST
Date: 2003-05-23 20:32:28
Message-ID: 20030523203228.GA26249@wolff.to
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

On Fri, May 23, 2003 at 13:03:52 -0700,
Jeff Pogodzinski <jrpogo(at)yahoo(dot)com> wrote:
> Hi Bruno,
>
> > It is generally bad design to hold database locks while waiting for
> > user input. It is generally better to keep information about updates
> > in a table and have the applications use this information to advise
> > or prevent conncurrent updates to the same data by different people.
>
> How would I advise of prevent conncurrent updates without locks?

You use tables in your database that are checked by the application.
Typically you would store information about what data is being worked
on and who is working on it. That way you don't block the database waiting
for input from humans. If two people want to work on the same data at the
same time, the application decides how to handle that. You may want to
prevent it (with some way to override) or just issue a warning. You may
also want to issue a warning to the second person to commit their changes
warning them that the data has been changed since they started their work.

In response to

Browse pgsql-sql by date

  From Date Subject
Next Message PeterKorman 2003-05-24 00:43:38 Re: language "plpgsql" does not exist
Previous Message Achilleus Mantzios 2003-05-23 18:29:44 Re: Inquiry From Form [pgsql]