Re: how to ensure a client waits for a previous transaction to finish? - Mailing list pgsql-general

From Merlin Moncure
Subject Re: how to ensure a client waits for a previous transaction to finish?
Date
Msg-id b42b73150912082128n7ca3190v4827ba5acc46a30b@mail.gmail.com
Whole thread Raw
In response to Re: how to ensure a client waits for a previous transaction to finish?  (Dan Kortschak <dan.kortschak@adelaide.edu.au>)
Responses Re: how to ensure a client waits for a previous transaction to finish?  (Dan Kortschak <dan.kortschak@adelaide.edu.au>)
List pgsql-general
On Tue, Dec 8, 2009 at 10:13 PM, Dan Kortschak
<dan.kortschak@adelaide.edu.au> wrote:
> I've spoken to people on the torque user mailing list and tried merlin's
> suggestion below (which looked like it should work - but unfortunately
> did not prevent the problem).
>
> >From working through things with the torque list, it seems to be the
> case that postgresql is behaving differently because it is not attached
> to a terminal (this has caused problems for others on that list with
> sqlite and mysql).
>
> Can anyone confirm/refute this? And if it is the case, is there
> something that I can do about it?

Advisory locks are basically only useful if the locker of the resource
maintains a database session (that is, stays connected and enjoys
private use of that connection) for the duration of the lock.  Aside:
there is a way to hold locks from unconnected sessions...2PC, but the
feature is dangerous and probably not useful in your case.

Can you give a clearer explanation of the problem?  You can monitor
the output from:
select * from pg_stat_activity;
in psql.  Take special note of 'idle in transaction'  backends and if
the connection is being regenerated behind your back by watching  for
the pid changing.

merlin

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: how to ensure a client waits for a previous transaction to finish?
Next
From: Merlin Moncure
Date:
Subject: Re: Excessive (and slow) fsync() within single transaction