From: | Dan Kortschak <dan(dot)kortschak(at)adelaide(dot)edu(dot)au> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: how to ensure a client waits for a previous transaction to finish? |
Date: | 2009-12-09 08:06:38 |
Message-ID: | 1260345998.10122.7.camel@epistle |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Thanks Tom,
That was my initial view and I'm still not convinced that I'm wrong - I
can see no way that the server can tell that the query came from a
process without a terminal (though I may be missing something here).
Unfortunately I'm working at the boundary of my knowledge for both
torque and pg, so it's difficult to be certain.
I should point out that the pg queries are not submitted by psql, but
from perl using the perl DBI. This does not fundamentally change the
argument.
The thing that worries me is that I can't replicate the fault any way
but but calling with a qsub.
Unfortunately I need the machine to do this work over the next few days,
so I can't look into the details (I can run the jobs without using
torque, but it makes life easier).
The strace -f is a good suggestion and I'll try if once this set of jobs
has been processed (each takes ~40-60 hours, and unfortunately the test
case takes about 20-30 minutes - I suspect that this problem would not
arise with more convenient tests).
cheers
Dan
On Wed, 2009-12-09 at 00:22 -0500, Tom Lane wrote:
> That seems unlikely. My best guess at this point is that for some
> reason the torque scripts are failing to wait for psql to exit.
> You might possibly be able to confirm or deny this by watching the
> whole process tree with "strace -f" or local equivalent.
From | Date | Subject | |
---|---|---|---|
Next Message | Dan Kortschak | 2009-12-09 08:19:17 | Re: how to ensure a client waits for a previous transaction to finish? |
Previous Message | Guillaume Lelarge | 2009-12-09 08:06:12 | Re: Rules and conditions |