About the stats_temp_directory, I didn't run as root...
Now I'm sure the configurations are correct.
I think, I have too much IO to use stats. I will ever have this message...
Maybe I can disable this option.
Do you know what it really impact ?
Thanks.
Math
2013/5/24 Mathieu Guerin
> Hello,
Hello,
Thanks a lot for your answers.
> You should get it...
> stats_temp_directory |
pg_stat_tmp | Writes temporary
statistics files to the specified directory.
I don't know why i don't get it. I am in 9.1 version...
Moreover, when I mount pg_stat_tm
On Thu, May 23, 2013 at 9:31 PM, Mathieu Guerin
wrote:
> What are the consequences ? Because this file will be remove if the server
> reboot.
>
Those temporary statistics are stored in global directory when server shuts
down, so the risk here would be to lose a portion of this data in the case
of
Mathieu Guerin escribió:
> Hello,
>
> I am facing a problem with pgstat as my subject says. I known, some topics
> are open about that, but I would like to go deeper.
>
> Some person told that the better way to don't have this message anymore is
> to configure pgstat.stat to be loaded in the RAM
Hello,
I am facing a problem with pgstat as my subject says. I known, some topics
are open about that, but I would like to go deeper.
Some person told that the better way to don't have this message anymore is
to configure pgstat.stat to be loaded in the RAM with a tmpfs mount point.
What are the
Hello,
I am facing a problem with pgstat as my subject says. I known, some topics
are open about that, but I would like to go deeper.
Some person told that the better way to don't have this message anymore is
to configure pgstat.stat to be loaded in the RAM with a tmpfs mount point.
What are the
While doing some pgbench testing on a new server with 9.1.1, I noticed
quite a lot of $subject in the logs. I did some Googling and found this
previous thread:
http://archives.postgresql.org/pgsql-hackers/2010-01/msg02897.php It
doesn't seem like the issue was resolved?
I did:
# pgbench -i -
2010/1/29 Greg Smith :
> I just found a few of these errors in a log file during some pgbench testing
> tonight. Linux, recent CVS HEAD; given the range of systems and versions
> this has been reported against now, this bug doesn't look like a platform or
> version/build specific issue.
>
> Unf
I just found a few of these errors in a log file during some pgbench
testing tonight. Linux, recent CVS HEAD; given the range of systems and
versions this has been reported against now, this bug doesn't look like
a platform or version/build specific issue.
Unfortunately the instance I had up
Il 21/01/2010 03:33, Jaime Casanova ha scritto:
On Wed, Jan 20, 2010 at 9:32 PM, Jaime Casanova
wrote:
On Wed, Jan 20, 2010 at 6:20 PM, Sergey E. Koposov wrote:
Hello hackers,
I've recently hit the message "WARNING: pgstat wait timeout" with PG 8.4.2.
i see the same yesterday when initdb
On Wed, Jan 20, 2010 at 9:32 PM, Jaime Casanova
wrote:
> On Wed, Jan 20, 2010 at 6:20 PM, Sergey E. Koposov wrote:
>> Hello hackers,
>>
>> I've recently hit the message "WARNING: pgstat wait timeout" with PG 8.4.2.
>
> i see the same yesterday when initdb a freshly compiled 8.5dev +
> lock_timeo
On Wed, Jan 20, 2010 at 6:20 PM, Sergey E. Koposov wrote:
> Hello hackers,
>
> I've recently hit the message "WARNING: pgstat wait timeout" with PG 8.4.2.
i see the same yesterday when initdb a freshly compiled 8.5dev +
lock_timeout patch
i thought maybe it was related to that patch and was thin
Hello hackers,
I've recently hit the message "WARNING: pgstat wait timeout" with PG
8.4.2.
I saw some reports about that message in the -bugs mailing list
http://archives.postgresql.org/pgsql-bugs/2009-12/msg00175.php
http://archives.postgresql.org/pgsql-bugs/2009-07/msg00081.php
where the bac
13 matches
Mail list logo
