Jeff Janes writes:
> On Wed, Mar 12, 2014 at 7:42 AM, Tom Lane wrote:
>> We've seen sporadic reports of that sort of behavior for years, but no
>> developer has ever been able to reproduce it reliably. Now that you've
>> got a reproducible case, do you want to poke into it and see what's going
>
On Wed, Mar 12, 2014 at 7:42 AM, Tom Lane wrote:
> Kouhei Kaigai writes:
> > WARNING: pgstat wait timeout
> > WARNING: pgstat wait timeout
> > WARNING: pgstat wait timeout
> > WARNING: pgstat wait timeout
>
> > Once I got above messages, write performance is dramatically
> > degraded, even t
On 12 Březen 2014, 14:54, Kouhei Kaigai wrote:
> It is another topic from the main thread,
>
> I noticed the following message under the test cases that
> takes heavy INSERT workload; provided by Haribabu.
>
> [kaigai@iwashi ~]$ createdb mytest
> [kaigai@iwashi ~]$ psql -af ~/cache_scan.sql mytest
Kouhei Kaigai writes:
> WARNING: pgstat wait timeout
> WARNING: pgstat wait timeout
> WARNING: pgstat wait timeout
> WARNING: pgstat wait timeout
> Once I got above messages, write performance is dramatically
> degraded, even though I didn't take detailed investigation.
> I could reproduce i
On Fri, May 11, 2012 at 3:35 PM, Tom Lane wrote:
> Magnus Hagander writes:
>> On Thu, May 10, 2012 at 6:52 PM, Tom Lane wrote:
>>> Oh ... while hacking win32 PGSemaphoreLock I saw that it has a *seriously*
>>> nasty bug: it does not reset ImmediateInterruptOK before returning.
>>> How is it that
Magnus Hagander writes:
> On Thu, May 10, 2012 at 6:52 PM, Tom Lane wrote:
>> Oh ... while hacking win32 PGSemaphoreLock I saw that it has a *seriously*
>> nasty bug: it does not reset ImmediateInterruptOK before returning.
>> How is it that Windows machines aren't falling over constantly?
> Hmm
On Thu, May 10, 2012 at 6:52 PM, Tom Lane wrote:
> I wrote:
>> Hence I think we oughta swap the order of those two array
>> elements. (Same issue in PGSemaphoreLock, btw, and I'm suspicious of
>> pgwin32_select.)
>
> Oh ... while hacking win32 PGSemaphoreLock I saw that it has a *seriously*
> nas
I wrote:
> Hence I think we oughta swap the order of those two array
> elements. (Same issue in PGSemaphoreLock, btw, and I'm suspicious of
> pgwin32_select.)
Oh ... while hacking win32 PGSemaphoreLock I saw that it has a *seriously*
nasty bug: it does not reset ImmediateInterruptOK before return
Magnus Hagander writes:
> On May 10, 2012 4:59 PM, "Tom Lane" wrote:
>> I spent some time staring at the Windows WaitLatchOrSocket code myself.
>> The only thing I could find that seemed wrong is that in the event
>> array, we list the latch's event before pgwin32_signal_event. The
>> Microsoft
On May 10, 2012 4:59 PM, "Tom Lane" wrote:
>
> I wrote:
> > Last night I changed the stats collector process to use
> > WaitLatchOrSocket instead of a periodic forced wakeup to see whether
> > the postmaster has died. This morning I observe that several Windows
> > buildfarm members are showing r
I wrote:
> Last night I changed the stats collector process to use
> WaitLatchOrSocket instead of a periodic forced wakeup to see whether
> the postmaster has died. This morning I observe that several Windows
> buildfarm members are showing regression test failures caused by
> unexpected "pgstat w
Hi,
I Disabled autovacuuming and the warnings stopped logging.
After enabling Autovacuuming, the warnings again started logging.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/pgstat-wait-timeout-tp5078125p5444033.html
Sent from the PostgreSQL - hackers mailing list arc
Hi,
Any ideas on this?
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/pgstat-wait-timeout-tp5078125p5165651.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make change
Thanks, i missed that.
After doing these changes, following is the observation:
1. The size of the pgstat file is 86KB. Last edited was when i moved the
file location to RAMdisk.
2. The issue persists. I am seeing continuous logs:
2012-01-05 00:00:06 JST WARNING: pgstat wait timeout
2012-01-05
On 4 Leden 2012, 13:17, pratikchirania wrote:
> I have installed RAMdisk and pointed the parameter:
>
> #stats_temp_directory = 'B:\pg_stat_tmp'
> I also tried #stats_temp_directory = 'B:/pg_stat_tmp'
>
> But, still there is no file created in the RAM disk.
> The previous stat file is touched even
I have installed RAMdisk and pointed the parameter:
#stats_temp_directory = 'B:\pg_stat_tmp'
I also tried #stats_temp_directory = 'B:/pg_stat_tmp'
But, still there is no file created in the RAM disk.
The previous stat file is touched even after the change is made. (I have
restarted the service af
On 12/28/2011 09:34 AM, Alvaro Herrera wrote:
Excerpts from Steve Crawford's message of mié dic 28 13:24:37 -0300 2011:
On 12/28/2011 05:05 AM, Alvaro Herrera wrote:
Excerpts from Steve Crawford's message of mar dic 27 22:51:06 -0300 2011:
I have a system (9.0.4 on Ubuntu Server 10.04 LTS x86_
Excerpts from Steve Crawford's message of mié dic 28 13:24:37 -0300 2011:
> On 12/28/2011 05:05 AM, Alvaro Herrera wrote:
> > Excerpts from Steve Crawford's message of mar dic 27 22:51:06 -0300 2011:
> >> I have a system (9.0.4 on Ubuntu Server 10.04 LTS x86_64) that is
> >> currently in test/dev
On 12/28/2011 05:05 AM, Alvaro Herrera wrote:
Excerpts from Steve Crawford's message of mar dic 27 22:51:06 -0300 2011:
I have a system (9.0.4 on Ubuntu Server 10.04 LTS x86_64) that is
currently in test/dev mode. I'm currently seeing the following messages
occurring every few seconds:
...
Dec
Excerpts from Steve Crawford's message of mar dic 27 22:51:06 -0300 2011:
> I have a system (9.0.4 on Ubuntu Server 10.04 LTS x86_64) that is
> currently in test/dev mode. I'm currently seeing the following messages
> occurring every few seconds:
>
> ...
> Dec 27 17:43:22 foo postgres[23693]: [
On 12/20/2011 05:13 AM, pratikchirania wrote:
Would this be alleviated by setting stats_temp_dir to point to a ramdisk?
I am not aware how to do this. I am using a windows server OS.
The conf file has the entry : #stats_temp_directory = 'pg_stat_tmp'
What do I change it to? Please elucidate.
>Would this be alleviated by setting stats_temp_dir to point to a ramdisk?
I am not aware how to do this. I am using a windows server OS.
The conf file has the entry : #stats_temp_directory = 'pg_stat_tmp'
What do I change it to? Please elucidate.
--
View this message in context:
http://postgre
On 12/19/2011 11:45 AM, Robert Haas wrote:
On Mon, Dec 19, 2011 at 10:02 AM, pratikchirania wrote:
Version upgrade: hmm.. Is there any fix/change related to this issue in
9.0.6?
You could read the release notes for those minor version upgrades.
Based on a quick look through the commit logs,
On Mon, Dec 19, 2011 at 10:02 AM, pratikchirania wrote:
> Version upgrade: hmm.. Is there any fix/change related to this issue in
> 9.0.6?
You could read the release notes for those minor version upgrades.
Based on a quick look through the commit logs, and a quick grep of
release-9-0.sgml, I don
OS: I am using Windows server 2003
Version upgrade: hmm.. Is there any fix/change related to this issue in
9.0.6?
If yes, I will upgrade in next scheduled downtime (I am using this as
production server)...
postgres queries are very occasionly used (a set of calls once in 30
minutes).. so I guess
On 15 Prosinec 2011, 19:42, pratikchirania wrote:
> Size of pgstat.stat file: 86KB
That's pretty small.
> I did not understand the second part. Where do I get "iostat -x 1"
> message?
> (Its not present in any file in the pg_log folder)
iostat is not part of PostgreSQL, it's a tool used to displ
Size of pgstat.stat file: 86KB
I did not understand the second part. Where do I get "iostat -x 1" message?
(Its not present in any file in the pg_log folder)
I am using postgres 9.0.1
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/pgstat-wait-timeout-tp5078125p5078391
On 15 Prosinec 2011, 18:19, Magnus Hagander wrote:
> On Thu, Dec 15, 2011 at 18:13, Tomas Vondra wrote:
>> On 15 Prosinec 2011, 17:55, pratikchirania wrote:
>>> Hi,
>>>
>>> I am having a scenario where I get consistent warnings in the pglog
>>> folder:
>>>
>>> 2011-12-11 00:00:03 JST WARNING: pgs
On Thu, Dec 15, 2011 at 18:13, Tomas Vondra wrote:
> On 15 Prosinec 2011, 17:55, pratikchirania wrote:
>> Hi,
>>
>> I am having a scenario where I get consistent warnings in the pglog
>> folder:
>>
>> 2011-12-11 00:00:03 JST WARNING: pgstat wait timeout
>> 2011-12-11 00:00:14 JST WARNING: pgstat
On 15 Prosinec 2011, 17:55, pratikchirania wrote:
> Hi,
>
> I am having a scenario where I get consistent warnings in the pglog
> folder:
>
> 2011-12-11 00:00:03 JST WARNING: pgstat wait timeout
> 2011-12-11 00:00:14 JST WARNING: pgstat wait timeout
> 2011-12-11 00:00:24 JST WARNING: pgstat wait
On Thu, Aug 11, 2011 at 10:30 AM, Tom Lane wrote:
> Andres Freund writes:
>>> --On 10. August 2011 21:54:06 +0300 Heikki Linnakangas
>>> wrote:
So my theory is that if the I/O is really busy, write() on the stats file
blocks for more than 5 seconds, and you get the timeout.
>
>> Yes, I
Andres Freund writes:
>> --On 10. August 2011 21:54:06 +0300 Heikki Linnakangas
>> wrote:
>>> So my theory is that if the I/O is really busy, write() on the stats file
>>> blocks for more than 5 seconds, and you get the timeout.
> Yes, I have seen it several times as well. I can actually reprodu
On Thursday, August 11, 2011 11:49:12 Bernd Helmle wrote:
> --On 10. August 2011 21:54:06 +0300 Heikki Linnakangas
>
> wrote:
> > So my theory is that if the I/O is really busy, write() on the stats
> > file
> > blocks for more than 5 seconds, and you get the timeout.
>
> I've seen it on custome
--On 10. August 2011 21:54:06 +0300 Heikki Linnakangas
wrote:
So my theory is that if the I/O is really busy, write() on the stats file
blocks for more than 5 seconds, and you get the timeout.
I've seen it on customer instances with very high INSERT peak loads (several
dozens backends IN
On 10.08.2011 21:45, Tom Lane wrote:
We occasionally see $SUBJECT in the buildfarm, and I've also recently
had reports of them from Red Hat customers. The obvious theory is that
these reflect high load preventing the stats collector from responding,
but it would really take pretty crushing load
35 matches
Mail list logo
