Search Postgresql Archives

Re: how to ensure a client waits for a previous transaction to finish?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Dec 8, 2009 at 10:13 PM, Dan Kortschak
<dan.kortschak@xxxxxxxxxxxxxxx> 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

-- 
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux