You're right I have forgotten to say, the OS is RHEL 7.
Actually I'm reading about.
Thanks!
-
Dame un poco de fe, eso me bastará.
Rozvo Ware Solutions
--
View this message in context:
http://www.postgresql-archive.org/postgres-dbname-dbuser-9-9-9-9--PARSE-waiting-tp5968923p5969564.
On Fri, Jun 30, 2017 at 11:36 AM, DrakoRod wrote:
> > Do you control the app?
>
> Nop Just I know how it's developed.
>
> > The app has a pooling component and you still are having problems, have
> > you looked at what the pooler is actually doing?
>
> As far as I know, the wildfly's jdbc pool. N
> Do you control the app?
Nop Just I know how it's developed.
> The app has a pooling component and you still are having problems, have
> you looked at what the pooler is actually doing?
As far as I know, the wildfly's jdbc pool. No really I don't know what are
doing. I suspect that problem i
On Thu, Jun 29, 2017 at 7:30 PM, Adrian Klaver
wrote:
> On 06/29/2017 10:03 AM, DrakoRod wrote:
>
>> To expand information, the application are written in Grails on wildfly
>> with
>> pool connections.
>>
>
> Do you control the app?
>
> The app has a pooling component and you still are having pro
On 06/29/2017 10:03 AM, DrakoRod wrote:
To expand information, the application are written in Grails on wildfly with
pool connections.
Do you control the app?
The app has a pooling component and you still are having problems, have
you looked at what the pooler is actually doing?
I didn't
On Thu, Jun 29, 2017 at 10:03 AM, DrakoRod wrote:
> I can't close connections on the application side. How I close connections
> on the database side? With pg_terminate_backend, pg_cancel_backend or
> exists
> other function? I didn't want terminate backends because all connections
> state was ac
To expand information, the application are written in Grails on wildfly with
pool connections.
I didn't have time to check pg_locks with detail, I'll configure the
connections logs to monitoring those.
I can't close connections on the application side. How I close connections
on the database side
On Tue, 27 Jun 2017 16:16:53 -0700 (MST)
DrakoRod wrote:
> Yep, the real problem was all connections are used up. A ps command showed
> this:
>
> postgres 1172 23340 1 13:00 ?00:01:23 postgres: dbsomething
> dbsomething 8.8.8.1[34024] PARSE waiting
> postgres 1527 23340 3 13:07 ?
On 06/27/2017 04:16 PM, DrakoRod wrote:
Yep, the real problem was all connections are used up. A ps command showed
this:
postgres 1172 23340 1 13:00 ?00:01:23 postgres: dbsomething
dbsomething 8.8.8.1[34024] PARSE waiting
postgres 1527 23340 3 13:07 ?00:02:47 postgres: dbsome
Yep, the real problem was all connections are used up. A ps command showed
this:
postgres 1172 23340 1 13:00 ?00:01:23 postgres: dbsomething
dbsomething 8.8.8.1[34024] PARSE waiting
postgres 1527 23340 3 13:07 ?00:02:47 postgres: dbsomething
dbsomething 8.8.8.2[49193] PARSE wai
On Tue, Jun 27, 2017 at 3:41 PM, Melvin Davidson
wrote:
> *His problem is NOT 'idle in transaction' per se. It is all connections
> are used up.*
> *Hence the need for pg_bouncer for connection pooling.*
>
>
Whether pg_bouncer provides a viable solution is just as big an unknown as
whether "idle
On 06/27/2017 03:41 PM, Melvin Davidson wrote:
On Tue, Jun 27, 2017 at 6:32 PM, Adrian Klaver
*His problem is NOT 'idle in transaction' per se. It is all connections
are used up.*
Not following. The 'idle in transaction' queries are coming in through a
connection so having them around is
On Tue, 27 Jun 2017 18:41:25 -0400
Melvin Davidson wrote:
> On Tue, Jun 27, 2017 at 6:32 PM, Adrian Klaver
> wrote:
>
> > On 06/27/2017 01:10 PM, DrakoRod wrote:
> >
> >> Hi folks.
> >>
> >> Today I had a problem with production's database PostgreSQL version
> >> 9.4.4.9.
> >> The server have m
On Tue, Jun 27, 2017 at 6:32 PM, Adrian Klaver
wrote:
> On 06/27/2017 01:10 PM, DrakoRod wrote:
>
>> Hi folks.
>>
>> Today I had a problem with production's database PostgreSQL version
>> 9.4.4.9.
>> The server have max_connections set to 200, but today I reviewed
>> pg_stat_activity and saw 199
On 06/27/2017 01:10 PM, DrakoRod wrote:
Hi folks.
Today I had a problem with production's database PostgreSQL version 9.4.4.9.
The server have max_connections set to 200, but today I reviewed
pg_stat_activity and saw 199 active connections, obviously the server
rejected any new connection and th
On Tue, Jun 27, 2017 at 1:10 PM, DrakoRod wrote:
> postgres 9741 23340 9 14:55 ?00:00:47 postgres: dbname user
> 8.8.8.8[54286] idle in transaction
>
> Any suggestions?
>
There is a serious lack of information provided here but "idle in
transaction" sessions are generally problematic
On Tue, Jun 27, 2017 at 4:10 PM, DrakoRod wrote:
> Hi folks.
>
> Today I had a problem with production's database PostgreSQL version
> 9.4.4.9.
> The server have max_connections set to 200, but today I reviewed
> pg_stat_activity and saw 199 active connections, obviously the server
> rejected any
Hi folks.
Today I had a problem with production's database PostgreSQL version 9.4.4.9.
The server have max_connections set to 200, but today I reviewed
pg_stat_activity and saw 199 active connections, obviously the server
rejected any new connection and the production stopped.
I saw another posts
18 matches
Mail list logo
