Just chiming in quickly,
We experienced exactly the same behavior with pg 9.4.
It was consistent across the 18 database servers that we upgraded from
9.3 to 9.4.
A job would complete successfully, and then just remain in 'running' state.
We tried purging and re-installing pg and pgadmin/agent cl
On 07/21/2015 11:29 PM, Ashesh Vashi wrote:
> On Wed, Jul 22, 2015 at 11:56 AM, Sanket Mehta
> mailto:sanket.me...@enterprisedb.com>>
> wrote:
>
> Hi Dave,
>
> As per our discussion, I have tried to reproduce the issue, but it
> seems jobs are running fine without any problem.
> H
On Wed, Jul 22, 2015 at 11:56 AM, Sanket Mehta <
sanket.me...@enterprisedb.com> wrote:
> Hi Dave,
>
> As per our discussion, I have tried to reproduce the issue, but it seems
> jobs are running fine without any problem.
> Hence the issue is not reproducible on my system.
>
Josh,
As we're unable t
Hi Dave,
As per our discussion, I have tried to reproduce the issue, but it seems
jobs are running fine without any problem.
Hence the issue is not reproducible on my system.
Regards,
Sanket Mehta
Sr Software engineer
Enterprisedb
On Tue, Jul 21, 2015 at 9:52 AM, Josh Berkus wrote:
> On 07/20/
On 07/20/2015 08:01 AM, Dave Page wrote:
>> Suggestion to resolve the issue:
>>
>> get the max value of ID from table before insert query and run the
>> sequence till we get the max(ID)+1 and then we execute the insert statement
>> with this new value as ID.
>
> We're not doing that - it'
Hi
On Mon, Jul 20, 2015 at 12:49 PM, Sanket Mehta
wrote:
> Hi Dave,
>
> I have tried to reproduce the same in my system by resetting the pgagent
> sequences to 1.
>
> Below is the results I have came across:
>
> the job is not getting executed and its current status is "i" (no
> steps fo
Hi Dave,
I have tried to reproduce the same in my system by resetting the pgagent
sequences to 1.
Below is the results I have came across:
the job is not getting executed and its current status is "i" (no
steps found ) although I have specified 2 steps for that job.
Below is the log en
Sure Dave,
I will try and let you know.
Regards,
Sanket Mehta
Sr Software engineer
Enterprisedb
On Mon, Jul 13, 2015 at 7:44 PM, Dave Page wrote:
> Sanket, can you reproduce this?
>
> On Fri, Jul 10, 2015 at 5:41 PM, Josh Berkus wrote:
> > On 07/10/2015 07:16 AM, Dave Page wrote:
> >> Are you
Sanket, can you reproduce this?
On Fri, Jul 10, 2015 at 5:41 PM, Josh Berkus wrote:
> On 07/10/2015 07:16 AM, Dave Page wrote:
>> Are you able to get a stacktrace from a running instance that's hung?
>
> Yes, but it's not doing anything, it's just polling for the next job.
>
>> Also, does setting
On 07/10/2015 07:16 AM, Dave Page wrote:
> Are you able to get a stacktrace from a running instance that's hung?
Yes, but it's not doing anything, it's just polling for the next job.
> Also, does setting the logging level to debug reveal anything useful
> in the filesystem logs? (pgagent -l2
On Tue, Jul 7, 2015 at 12:02 AM, Josh Berkus wrote:
> On 07/06/2015 10:26 AM, Josh Berkus wrote:
>> All,
>>
>> On the same server with the SQL errors (sequences are cleaned up now),
>> we're having pgagent start all jobs in the "r" state, log the first step
>> in each job in the "r" state, and the
On 07/06/2015 10:26 AM, Josh Berkus wrote:
> All,
>
> On the same server with the SQL errors (sequences are cleaned up now),
> we're having pgagent start all jobs in the "r" state, log the first step
> in each job in the "r" state, and then hang forever (or, at least for
> three days). At this po
All,
On the same server with the SQL errors (sequences are cleaned up now),
we're having pgagent start all jobs in the "r" state, log the first step
in each job in the "r" state, and then hang forever (or, at least for
three days). At this point, 8 different jobs are in "r" state.
In pg_stat_act
13 matches
Mail list logo
