Thanks Adrian and Tom.
Tom wrote:
>
> It's not entirely clear what your question is, but here are some possible
> answers:
>
> 1. For quite some time now, the "query" column in pg_stat_activity has
> been defined as "the query currently or most recently run by the session";
> it's intentional tha
Johann Spies writes:
> I have read quite a variety of stuff on the internet about an explanation
> for idle postgresql processes but still do not understand the following
> typical scenario.
> This is on Debian (postgresql 9.4.4-1.pgdg80+1).
> Running the following (as user crest) on an empty ta
On 08/05/2015 12:38 AM, Johann Spies wrote:
I have read quite a variety of stuff on the internet about an
explanation for idle postgresql processes but still do not understand
the following typical scenario.
This is on Debian (postgresql 9.4.4-1.pgdg80+1).
Running the following (as user crest)
I have read quite a variety of stuff on the internet about an explanation
for idle postgresql processes but still do not understand the following
typical scenario.
This is on Debian (postgresql 9.4.4-1.pgdg80+1).
Running the following (as user crest) on an empty table using psql:
select * from w
ilto:t...@sss.pgh.pa.us]
Sent: Sunday, 27 September 2009 2:42 PM
To: Brendan Hill
Cc: 'Craig Ringer'; pgsql-general@postgresql.org
Subject: Re: [GENERAL] Idle processes chewing up CPU?
"Brendan Hill" writes:
> Makes sense to me. Seems to be happening rarely now.
>
"Brendan Hill" writes:
> I think I've confirmed the fix. Using a dirty disconnect generator, I was
> able to reliably recreate the problem within about 30-60 seconds. The
> symptoms were the same as before, however it occurred around SSL_write
> instead of SSL_read - I assume this was due to the a
"Brendan Hill" writes:
> Bit of a catch 22 - since it happens rarely, there's no definitive
> confirmation that it's fixed the problem.
> Also, not sure if I'm comfortable applying the change and recompiling
> myself, wouldn't have a clue where to start.
Uh, so you haven't actually tested it at a
though, seems like a good idea
regardless, what do you think?
Regards,
-Brendan
-Original Message-
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Sent: Sunday, 27 September 2009 2:42 PM
To: Brendan Hill
Cc: 'Craig Ringer'; pgsql-general@postgresql.org
Subject: Re: [GENERAL] Idle p
> Cc: 'Craig Ringer'; pgsql-general@postgresql.org
> Subject: Re: [GENERAL] Idle processes chewing up CPU?
> "Brendan Hill" writes:
>> My best interpretation is that an SSL client dirty disconnected while
>> running a request. This caused an infinite loop
5:25 AM
To: Brendan Hill
Cc: 'Craig Ringer'; pgsql-general@postgresql.org
Subject: Re: [GENERAL] Idle processes chewing up CPU?
"Brendan Hill" writes:
> My best interpretation is that an SSL client dirty disconnected while
> running a request. This caused an infinit
"Brendan Hill" writes:
> My best interpretation is that an SSL client dirty disconnected while
> running a request. This caused an infinite loop in pq_recvbuf(), calling
> secure_read(), triggering my_sock_read() over and over. Calling
> SSL_get_error() in secure_read() returns 10045 (either conne
Hi Craig, I've debugged the runaway process, though I'm not sure of the
solution yet.
My best interpretation is that an SSL client dirty disconnected while
running a request. This caused an infinite loop in pq_recvbuf(), calling
secure_read(), triggering my_sock_read() over and over. Calling
SSL_g
On 19/08/2009 1:34 PM, Brendan Hill wrote:
Hi Craig, thanks for the analysis. If I attach a debugger on the runaway
child process, will this halt execution for all the other child processes
(ie. freeze the server)? And, can I attach Visual Studio C++ 2008, or is
there a recommended debugger for W
endan Hill
Cc: pgsql-general@postgresql.org; 'Tom Lane'
Subject: Re: [GENERAL] Idle processes chewing up CPU?
On 19/08/2009 12:31 PM, Brendan Hill wrote:
> Hi Craig/Tom,
>
> I've managed to trap the full stack trace this time
The common part of those traces is:
&g
On 19/08/2009 12:31 PM, Brendan Hill wrote:
Hi Craig/Tom,
I've managed to trap the full stack trace this time
The common part of those traces is:
> ntdll.dll!KiFastSystemCallRet
> WS2_32.dll!WSARecv+0x65
> WSOCK32.dll!recv+0x31
> LIBEAY32.dll!BIO_sock_should_retry+0x57
> postgres.exe!my_soc
papers.com.au]
Sent: Wednesday, 5 August 2009 5:44 PM
To: Brendan Hill
Cc: 'Tom Lane'; pgsql-general@postgresql.org
Subject: RE: [GENERAL] Idle processes chewing up CPU?
On Wed, 2009-08-05 at 16:44 +1000, Brendan Hill wrote:
> Hi Craig,
>
> Sorry, I had the stack trace so I th
siveness is terrific.
-Brendan
-Original Message-
From: Craig Ringer [mailto:cr...@postnewspapers.com.au]
Sent: Wednesday, 5 August 2009 5:44 PM
To: Brendan Hill
Cc: 'Tom Lane'; pgsql-general@postgresql.org
Subject: RE: [GENERAL] Idle processes chewing up CPU?
On Wed, 2009-08-0
PM
To: Brendan Hill
Cc: 'Tom Lane'; pgsql-general@postgresql.org
Subject: RE: [GENERAL] Idle processes chewing up CPU?
On Wed, 2009-08-05 at 15:26 +1000, Brendan Hill wrote:
> I copied a few of the stack traces (at the end of this email), it kept
> changing each time I looked.
Yep, that
On Wed, 2009-08-05 at 16:44 +1000, Brendan Hill wrote:
> Hi Craig,
>
> Sorry, I had the stack trace so I thought it was enough. I'll make sure the
> debug environment is set up and post the full stack traces again.
No worries. Sorry it cost you time.
I've extended the wiki article on win32 debug
On Wed, 2009-08-05 at 15:26 +1000, Brendan Hill wrote:
> I copied a few of the stack traces (at the end of this email), it kept
> changing each time I looked.
Yep, that's to be expected. If the process is busy, unless it's in a
_REALLY_ simple infinite loop, it'll be looping through some non-triv
ould_retry+0x57
-Original Message-
From: Craig Ringer [mailto:cr...@postnewspapers.com.au]
Sent: Wednesday, 29 July 2009 8:09 PM
To: Brendan Hill
Cc: 'Tom Lane'; pgsql-general@postgresql.org
Subject: Re: [GENERAL] Idle processes chewing up CPU?
Craig Ringer wrote:
> Brendan Hill w
On Wed, Jul 29, 2009 at 12:08, Craig Ringer wrote:
> Craig Ringer wrote:
>>
>> Brendan Hill wrote:
>>>
>>> Hi Tom,
>>>
>>> Given it's on Windows, any suggestion for how I would get hold of this?
>>> (Process Monitor tool perhaps?)
>>
>> I think you can get stack traces from Process Monitor using "T
Craig Ringer wrote:
Brendan Hill wrote:
Hi Tom,
Given it's on Windows, any suggestion for how I would get hold of this?
(Process Monitor tool perhaps?)
I think you can get stack traces from Process Monitor using "Tools ->
Stack Summary". I find it a bit hard to interpret this data, though, a
Brendan Hill wrote:
Hi Tom,
Given it's on Windows, any suggestion for how I would get hold of this?
(Process Monitor tool perhaps?)
I think you can get stack traces from Process Monitor using "Tools ->
Stack Summary". I find it a bit hard to interpret this data, though, and
I'm not sure how
On Tue, Jul 28, 2009 at 7:17 PM, Brendan Hill wrote:
> Hi Tom,
>
> Given it's on Windows, any suggestion for how I would get hold of this?
> (Process Monitor tool perhaps?)
I'd bet there's a windows faq somewhere on system monitoring (googles)
Is this at all helpful, or is this problem beyond:
htt
l.org
Subject: Re: [GENERAL] Idle processes chewing up CPU?
"Brendan Hill" writes:
> Using the Process Explorer tool, I've noticed that a child postgres.exe is
> chewing up 25% of the CPU usage each (we have two dual-core CPUs,
presumably
> it's chewing up one core). Using
"Brendan Hill" writes:
> Using the Process Explorer tool, I've noticed that a child postgres.exe is
> chewing up 25% of the CPU usage each (we have two dual-core CPUs, presumably
> it's chewing up one core). Using SELECT * FROM pg_stat_activity, I located
> the process id (#3884), and it showed:
>
I recently migrated from MSSQL2000 to Postgres 8.3 for Windows, and overall
it's running great.
Using the Process Explorer tool, I've noticed that a child postgres.exe is
chewing up 25% of the CPU usage each (we have two dual-core CPUs, presumably
it's chewing up one core). Using SELECT * FROM
On Saturday 14 August 2004 11:17 pm, CSN wrote:
> I'm using regular pg_connect's. The processes
> eventually went away - was just wondering why they'd
> stick around.
>
Well, unless I misunderstand, when a script ends the connection should go away
and I think that means the postgres process suppo
I'm using regular pg_connect's. The processes
eventually went away - was just wondering why they'd
stick around.
CSN
On Saturday 14 August 2004 01:01 pm, CSN wrote:
> 'ps axu' shows:
>
> postgres 1249 0.0 0.7 20200 7296 ?S
> 11:50 0:00 postgres: user1 database1 127.0.0.1
idle
> pos
30 matches
Mail list logo
