On Tue, Aug 16, 2005 at 08:25:25PM +0200, Martijn van Oosterhout wrote:
> On Tue, Aug 16, 2005 at 11:05:35AM -0700, Bill Moseley wrote:
> > I've read over the docs on Concurrency Control but still not clear
> > about when transactions block other updates, and how to deal with that
> > on the application level.
> >
> > If I do a BEGIN and an UPDATE in one psql session and then try and do
> > an UPDATE in another psql session that UPDATE waits until either a
> > COMMIT or ROLLBACK.
> >
> > Is it common for applications using Postgresql to set a timer on
> > updates and abort?
>
> It is not normal to hold a transaction open while doing nothing. If you
> always send transactions without delays the issue doesn't come up
> because you never have to wait long enough for it matter.
Ok, that will be the normal case.
I was just wondering because I was running test code today and it
hung. I wondered what was happening and found out I left a psql
window open last night in the middle of a transaction. That shouldn't
happen in production.
So then I wondered if my application should set an alarm and timeout
with an error if, by odd chance, an update hangs. Trying to be a bit
more robust -- not that the application could recover, but at least it
could spit out an error other than hang.
--
Bill Moseley
moseley@xxxxxxxx
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
