Bruce Momjian wrote:
> Sorry, I introduced this bug.
To the gallows with you! :) Don't feel bad, there were several hackers
that missed the math on that one.
Joshua D. Drake
>
> ---
>
> Tom Lane wrote:
>> Benjamin Minsha
Sorry, I introduced this bug.
---
Tom Lane wrote:
> Benjamin Minshall <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> It's sounding like what you had was just transient bloat, in which case
> >> it might be useful to in
Tom Lane wrote:
> "Merlin Moncure" <[EMAIL PROTECTED]> writes:
>> On 3/2/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>>> "Merlin Moncure" <[EMAIL PROTECTED]> writes:
I think this explains the trigger that was blowing up my FC4 box.
>>> I dug in the archives a bit and couldn't find the report you'r
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> On 3/2/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>> "Merlin Moncure" <[EMAIL PROTECTED]> writes:
>>> I think this explains the trigger that was blowing up my FC4 box.
>>
>> I dug in the archives a bit and couldn't find the report you're
>> referring to?
On 3/2/07, Tom Lane <[EMAIL PROTECTED]> wrote:
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> On 3/1/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>> A further report led us to realize that 8.2.x in fact has a nasty bug
>> here: the stats collector is supposed to dump its stats to a file at
>> most eve
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> On 3/1/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>> A further report led us to realize that 8.2.x in fact has a nasty bug
>> here: the stats collector is supposed to dump its stats to a file at
>> most every 500 milliseconds, but the code was actually wa
On 3/1/07, Tom Lane <[EMAIL PROTECTED]> wrote:
Benjamin Minshall <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> It's sounding like what you had was just transient bloat, in which case
>> it might be useful to inquire whether anything out-of-the-ordinary had
>> been done to the database right be
Tom Lane wrote:
A further report led us to realize that 8.2.x in fact has a nasty bug
here: the stats collector is supposed to dump its stats to a file at
most every 500 milliseconds, but the code was actually waiting only
500 microseconds :-(. The larger the stats file, the more obvious
this pr
Benjamin Minshall <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> It's sounding like what you had was just transient bloat, in which case
>> it might be useful to inquire whether anything out-of-the-ordinary had
>> been done to the database right before the excessive-CPU-usage problem
>> started.
Tom Lane wrote:
Well, that's pretty interesting. What are your vacuuming arrangements
for this installation? Could the drop in file size have coincided with
VACUUM operations? Because the ultimate backstop against bloated stats
files is pgstat_vacuum_tabstat(), which is run by VACUUM and arran
Benjamin Minshall <[EMAIL PROTECTED]> writes:
> When I checked on the server this morning, the huge stats file has
> returned to a normal size. I set up a script to track CPU usage and
> stats file size, and it appears to have decreased from 90MB down to
> about 2MB over roughly 6 hours last ni
Tom Lane wrote:
I wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
Regarding temp tables, I'd think that the pgstat entries should be
getting dropped at some point in both releases. Maybe there's a bug
preventing that in 8.2?
Hmmm ... I did rewrite the backend-side code for that just recen
I wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
>> Regarding temp tables, I'd think that the pgstat entries should be
>> getting dropped at some point in both releases. Maybe there's a bug
>> preventing that in 8.2?
> Hmmm ... I did rewrite the backend-side code for that just recently for
>
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Regarding temp tables, I'd think that the pgstat entries should be
> getting dropped at some point in both releases. Maybe there's a bug
> preventing that in 8.2?
Hmmm ... I did rewrite the backend-side code for that just recently for
performance reaso
Tom Lane wrote:
> [EMAIL PROTECTED] writes:
> > While exploring this problem, I've noticed that one of the frequent insert
> > processes creates a few temporary tables to do post-processing. Is it
> > possible that the stats collector is getting bloated with stats from these
> > short-lived tempor
[EMAIL PROTECTED] writes:
> While exploring this problem, I've noticed that one of the frequent insert
> processes creates a few temporary tables to do post-processing. Is it
> possible that the stats collector is getting bloated with stats from these
> short-lived temporary tables? During period
> Benjamin Minshall <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> How many tables are visible in the pg_stats views?
>
>> There are about 15 databases in the cluster each with around 90 tables.
>> A count of pg_stats yields between 500 and 800 rows in each database.
>
> Sorry, I was imprecis
Benjamin Minshall <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> How many tables are visible in the pg_stats views?
> There are about 15 databases in the cluster each with around 90 tables.
> A count of pg_stats yields between 500 and 800 rows in each database.
Sorry, I was imprecise. The v
Tom Lane wrote:
Benjamin Minshall <[EMAIL PROTECTED]> writes:
Seems the problem may be related to a huge global/pgstat.stat file.
Under 8.1.5 it was about 1 MB; now it's 90 MB in 8.2.3.
Yoi. We didn't do anything that would bloat that file if it were
storing the same information as before. W
Benjamin Minshall <[EMAIL PROTECTED]> writes:
> Seems the problem may be related to a huge global/pgstat.stat file.
> Under 8.1.5 it was about 1 MB; now it's 90 MB in 8.2.3.
Yoi. We didn't do anything that would bloat that file if it were
storing the same information as before. What I'm betting
Tom Lane wrote:
Benjamin Minshall <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Can you gather some info about what it's doing?
strace'ing the stats collector might prove interesting, also if you have
built it with --enable-debug then oprofile results would be helpful.
I will gather some strace
Benjamin Minshall <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Can you gather some info about what it's doing?
>> strace'ing the stats collector might prove interesting, also if you have
>> built it with --enable-debug then oprofile results would be helpful.
> I will gather some strace info la
Tom Lane wrote:
OK, I was trying to correlate it with post-8.2.0 patches but evidently
that's the wrong tree to bark up. No, this isn't an expected behavior.
I talked with a co-worker and discovered that we went from 8.1.5 to
8.2.2, ran a few hours then went to 8.2.3 after the patch was rele
Benjamin Minshall <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Benjamin Minshall <[EMAIL PROTECTED]> writes:
>>> Since upgrading to 8.2.3 yesterday, the stats collector process has had
>>> very high CPU utilization; it is consuming roughly 80-90% of one CPU.
>>> The server seems a lot more sl
Tom Lane wrote:
Benjamin Minshall <[EMAIL PROTECTED]> writes:
Since upgrading to 8.2.3 yesterday, the stats collector process has had
very high CPU utilization; it is consuming roughly 80-90% of one CPU.
The server seems a lot more sluggish than it was before. Is this normal
operation for 8.2
Benjamin Minshall <[EMAIL PROTECTED]> writes:
> Since upgrading to 8.2.3 yesterday, the stats collector process has had
> very high CPU utilization; it is consuming roughly 80-90% of one CPU.
> The server seems a lot more sluggish than it was before. Is this normal
> operation for 8.2 or someth
Greetings,
Since upgrading to 8.2.3 yesterday, the stats collector process has had
very high CPU utilization; it is consuming roughly 80-90% of one CPU.
The server seems a lot more sluggish than it was before. Is this normal
operation for 8.2 or something I should look into correcting?
stat
27 matches
Mail list logo
