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

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Dan Kortschak <dan(dot)kortschak(at)adelaide(dot)edu(dot)au>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: how to ensure a client waits for a previous transaction to finish?
Date: 2009-12-07 23:33:11
Message-ID: b42b73150912071533sc53b076m48360c1c9bcc5d09@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Mon, Dec 7, 2009 at 5:32 PM, Dan Kortschak
<dan(dot)kortschak(at)adelaide(dot)edu(dot)au> wrote:
> Thanks to everyone who has answered this. The short answer is that
> torque is not behaving the way I expected and not the way I have ever
> seen it behave in the past. The I/O binding of these jobs may have
> something to do with this, but I will look into it further.
>
> cheers
>
> On Mon, 2009-12-07 at 13:26 -0800, John R Pierce wrote:
>> I'm totally unfamiliar with torque., but you probably need to tell
>> torque to run the first script and wait for it to return before
>> running
>> the rest, its probably launching a bunch concurrently.
>>
> That *shouldn't* be the case as the contents of a torque script should
> be run sequentially (many jobs depend on this and I've never seen job
> parts run out of order), just as a sh script is (they are actually just
> csh scripts in my case). My understanding is that the parallelisation
> occurs either through using MPI or other parallel compilers or running a
> number of torque jobs, BUT I've just tested the hypothesis by running it
> as a straight csh script - and it works perfectly, so there must be
> something like that going on. I'll ask some of our more experience
> torque admins about it. Thanks.

If it turns out you need to have a lock with a 'longer than
transaction' duration, maybe advisory locks are a good fit.

merlin

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message David Fetter 2009-12-08 00:46:00 Tuesday (PST8PDT) Jeff Davis Presents: Operator Exclusion Constraints
Previous Message Josip Rodin 2009-12-07 22:53:45 Re: freeradius postgresql sql query glitch