From: Mischa Sandberg <mischa@ca.sophos.com>
To: pgsql-performance@postgresql.org
Subject: Re: vacuuming problems continued
Date: Tue, 06 Jun 2006 12:38:09 -0700
Message-ID: <4485D9A1.30807@ca.sophos.com> (raw)
In-Reply-To: <4485D5C3.7010803@commandprompt.com>
References: <92d3a4950606010454y67293765o56001e8996975b45@mail.gmail.com>
<20060605204151.GC7071@phlogiston.dyndns.org>
<4485CECC.4040207@ca.sophos.com>
<4485D5C3.7010803@commandprompt.com>
Joshua D. Drake wrote:
>> - in our env, clients occasionally hit max_connections. This is a
>> known and (sort of) desired pushback on load. However, that sometimes
>> knocks pg_autovacuum out.
>
> That is when you use:
>
> superuser_reserved_connections
Blush. Good point. Though, when we hit max_connections on 7.4.8 systems,
it's been a lemonade-from-lemons plus that vacuuming didn't fire up on top of
everything else :-)
>> - db server goes down for any reason: same problem.
>
> I believe you can use
> stats_reset_on_server_start = on
We do. The problem is not the loss of pg_stat_user_tables.(n_tup_ins,...)
It's the loss of pg_autovacuum's CountAtLastVacuum (and ...Analyze)
numbers, which are kept in process memory. Never considered patching
pg_autovacuum to just sleep and try again, rather than exit, on a failed
db connection.
--
Engineers think that equations approximate reality.
Physicists think that reality approximates the equations.
Mathematicians never make the connection.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: mischa@ca.sophos.com
Subject: Re: vacuuming problems continued
In-Reply-To: <4485D9A1.30807@ca.sophos.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox