How many autovac workers are there?
Max_workers is set to 3. However, I've never seen more than one active
at a time.
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.c
Josh Berkus wrote:
> Tom,
>
> Neither database has and per-table autovacuum settings.
>
> However, since this is a production database, I had to try
> something, and set vacuum_cost_limit up to 1000. The issue with
> vacuuming one page at a time went away, or at least I have not seen
> it repeat
Tom,
Neither database has and per-table autovacuum settings.
However, since this is a production database, I had to try something,
and set vacuum_cost_limit up to 1000. The issue with vacuuming one page
at a time went away, or at least I have not seen it repeat in the last
16 hours.
--
> Josh, are you sure that both servers are identical in terms of both
> GUC-related and per-table autovacuum settings?
I should check per-table. GUC, yes, because the company has source
management for config files.
--
-- Josh Berkus
Josh Berkus writes:
>> But it shouldn't
>> be sleeping after each page with normal cost_delay parameters, should it?
> Right, that's why I find this puzzling. If the problem was easier to
> reproduce it would be easier to analyze.
The behavior would be explained if VacuumCostLimit were getting
>> pg_usleep calls select(), and some googling indicates that select() is
>> implemented as pollsys() on recent Solaris versions. So Josh's
>> assumption that those are delay calls seems plausible.
It's certainly the behavior I'm seeing otherwise. In "normal
operation", the number of pages read
Tom Lane wrote:
> Alvaro Herrera writes:
> > We don't call pollsys anywhere. Something in Solaris must be doing it
> > under the hood.
>
> pg_usleep calls select(), and some googling indicates that select() is
> implemented as pollsys() on recent Solaris versions. So Josh's
> assumption that th
Alvaro Herrera writes:
> We don't call pollsys anywhere. Something in Solaris must be doing it
> under the hood.
pg_usleep calls select(), and some googling indicates that select() is
implemented as pollsys() on recent Solaris versions. So Josh's
assumption that those are delay calls seems plau
Josh Berkus wrote:
> Basically, vacuuming of a table which normally takes about 20 minutes
> interactively with vacuum_cost_delay set to 20 had not completed after
> 14 hours. When I trussed it, I saw activity which indicated to me that
> autovacuum was doing a pollsys, presumably for cost_limit,
All,
We're having a very strange problem where autovacuum does not complete
on a Postgres 8.3.8/Solaris 5.10 system. The reason I say strange is:
this is one of a twin pair of identical systems,and the other system
does not have this issue.
Basically, vacuuming of a table which normally takes ab
10 matches
Mail list logo
