Chris Bowlby writes:
> Thanks for the response. I've run into situations where the database
> has also been removed just before pg_autovacuum was about to check, and
> there by kicks out an error (mainly an aesthetic issue, not really a
> functional issue).
That was fixed some time ago. It's no
Hi Alvaro,
Thanks for the response. I've run into situations where the database
has also been removed just before pg_autovacuum was about to check, and
there by kicks out an error (mainly an aesthetic issue, not really a
functional issue). If an option was added to PostgreSQL itself to
support th
Chris Bowlby wrote:
> Hi Guys,
>
> In relation to pg_autovacuum, I have a quick question, that I can't seem
> to find an answer to anywhere. I use a temporary database that only
> exists when certain scripts are running, and is dropped when the scripts
> are complete. In that process, I have seen
Hi Guys,
In relation to pg_autovacuum, I have a quick question, that I can't seem
to find an answer to anywhere. I use a temporary database that only
exists when certain scripts are running, and is dropped when the scripts
are complete. In that process, I have seen pg_autovacuum periodically
exami
On Fri, Feb 23, 2007 at 06:47:52PM -0500, Tom Lane wrote:
> I wrote:
> > I don't find this particularly important, because we have never intended
> > direct update of catalog entries to be a primary way of interacting with
> > the system. The current pg_autovacuum setup is a stopgap until the dust
I wrote:
> I don't find this particularly important, because we have never intended
> direct update of catalog entries to be a primary way of interacting with
> the system. The current pg_autovacuum setup is a stopgap until the dust
> has settled enough that we know what sort of long-term API we w
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Mark Stosberg wrote:
>> Adding a default of -1 seems like a more cumbersome way to express the
>> same thing to me.
> To be frank, I don't remember what the rationale was for not using
> NULLs. Simplicity of code, I guess.
We tend to avoid allowing fi
Mark Stosberg wrote:
> Jim C. Nasby wrote:
> > On Fri, Feb 23, 2007 at 04:08:45PM -0300, Alvaro Herrera wrote:
> >> Mark Stosberg wrote:
> >>> I just tried to add something to the pg_autovacuum table for the first
> >>> time today (with 8.1). I wanted to make the simplest possible entry:
> >>> Disa
Jim C. Nasby wrote:
> On Fri, Feb 23, 2007 at 04:08:45PM -0300, Alvaro Herrera wrote:
>> Mark Stosberg wrote:
>>> I just tried to add something to the pg_autovacuum table for the first
>>> time today (with 8.1). I wanted to make the simplest possible entry:
>>> Disable auto-vacuuming for a table. H
On Fri, Feb 23, 2007 at 04:08:45PM -0300, Alvaro Herrera wrote:
> Mark Stosberg wrote:
> > I just tried to add something to the pg_autovacuum table for the first
> > time today (with 8.1). I wanted to make the simplest possible entry:
> > Disable auto-vacuuming for a table. However, the data model
Mark Stosberg wrote:
> I just tried to add something to the pg_autovacuum table for the first
> time today (with 8.1). I wanted to make the simplest possible entry:
> Disable auto-vacuuming for a table. However, the data model requires
> that I also enter values for:
>
> vac_base_thresh
You can u
I just tried to add something to the pg_autovacuum table for the first
time today (with 8.1). I wanted to make the simplest possible entry:
Disable auto-vacuuming for a table. However, the data model requires
that I also enter values for:
vac_base_thresh
vac_scale_factor
anl_base_thres
anl_scale_f
> Tomas Vondra wrote:
>> Hello,
>>
>> I have a simple question about auto-vacuuming. We are running a Postgres
>> 8.1 and I've noticed that some of the tables are not analyzed by the
>> pg_autovacuum daemon. That is - when I select the rows from pg_class,
>> all the important values (relpages, r
I feel very ashamed, as I've found the reason - the pg_autovacuum was
not running at all :( About month ago we've upgraded to PG 8.1, since
then the database was running without a restart but noone noticed the
warning about enabling stats_start_collector/stats_row_level.
I've noticed that only for
Tomas Vondra wrote:
> Hello,
>
> I have a simple question about auto-vacuuming. We are running a Postgres
> 8.1 and I've noticed that some of the tables are not analyzed by the
> pg_autovacuum daemon. That is - when I select the rows from pg_class,
> all the important values (relpages, reltuple
Hello,
I have a simple question about auto-vacuuming. We are running a Postgres
8.1 and I've noticed that some of the tables are not analyzed by the
pg_autovacuum daemon. That is - when I select the rows from pg_class,
all the important values (relpages, reltuples) are 0.
I've noticed this i
Hari Bhaskaran <[EMAIL PROTECTED]> writes:
> Why does pg_autovacuum need locks on more than one table at a time?
It doesn't --- unless maybe you are considering system catalogs, in
which case I'd wonder why you need exclusive lock on a catalog.
If you can prove the contrary, let's see a test cas
This is causing a headache for us, if that is indeed true.
So we have code that goes like
begin;
lock table t1;
lock table t2;
...
...
Of course within our own code, we do make sure things are always locked
in the same order (so we wouldn't create deadlocks). We do, however, end
up in deadloc
For the ones triggered after hours the only other events close by would
be pg_dump kicking off a backup (full database dump). I do see now that
quite a few of the warnings are triggered right after the pg_dump
process ends.
The ones during the day (specific schemas or individual table) would be
t
"Mike G." <[EMAIL PROTECTED]> writes:
> I have the postgresql.conf escape_string_warning active on my Win32 machine.
> I have a couple databases on it which are static. When pg_autovacuum checks
> these static databases it is triggering the warning: "non standard use of \\
> in a string litera
Hi,
I have the postgresql.conf escape_string_warning active on my Win32 machine. I
have a couple databases on it which are static. When pg_autovacuum checks
these static databases it is triggering the warning: "non standard use of \\ in
a string literal at character 128 or character 355" depe
On Tue, Dec 13, 2005 at 01:24:36PM +0200, Sim Zacks wrote:
> Where can I change the statistic targets?
See the readme for pg_autovacuum. As I mentioned, -V is one of the
parameters you want to track.
> These details for each table are written at the beginning, when I start it.
>
> [2005-12-13 12
Where can I change the statistic targets?
These details for each table are written at the beginning, when I start it.
[2005-12-13 12:38:45 IST] INFO: table name:
sales."public"."productdetails"
[2005-12-13 12:38:45 IST] INFO: relid: 9451256; relisshared: 0
[2005-12-13 12:38:45 I
On Tue, Dec 13, 2005 at 10:43:14AM +0200, Sim Zacks wrote:
> This is a sampling of the debug output.
>
> [2005-12-13 09:43:47 IST] DEBUG: 33 All DBs checked in: 278300 usec,
> will sleep for 300 secs.
> [2005-12-13 09:48:47 IST] DEBUG: 34 All DBs checked in: 171112 usec,
> will sleep for 300
This is a sampling of the debug output.
[2005-12-13 09:43:47 IST] DEBUG: 33 All DBs checked in: 278300 usec,
will sleep for 300 secs.
[2005-12-13 09:48:47 IST] DEBUG: 34 All DBs checked in: 171112 usec,
will sleep for 300 secs.
[2005-12-13 09:53:47 IST] DEBUG: updating the database list
On Wed, Dec 07, 2005 at 12:11:22PM +0200, Sim Zacks wrote:
> select version()
> "PostgreSQL 8.0.1 on i686-pc-linux-gnu, compiled by GCC
> i686-pc-linux-gnu-gcc (GCC) 3.3.5 (Gentoo Linux 3.3.5-r1, ssp-3.3.2-3,
> pie-8.7.7.1)"
>
> I am using PG_Autovacuum with postgresql 8.01 and it doesn't seem
select version()
"PostgreSQL 8.0.1 on i686-pc-linux-gnu, compiled by GCC
i686-pc-linux-gnu-gcc (GCC) 3.3.5 (Gentoo Linux 3.3.5-r1, ssp-3.3.2-3,
pie-8.7.7.1)"
I am using PG_Autovacuum with postgresql 8.01 and it doesn't seem to be
doing anything. I've seen it work on other machines where a lo
> When installing pg_autovacuum as Windows service, should user
> that makes connection be the service account or a superuser ?
> For example, I have service account "postgres_service" and
> database superuser "postgres". Which one should be used in
> following script:
> @echo off
> set TARGET_D
When installing pg_autovacuum as Windows service,
should user that makes connection be the service account or a superuser
?
For example, I have service account
"postgres_service" and database superuser "postgres". Which one should be used
in following script:
@echo off
set TARGET_DISC=C:echo
From: "Tom Lane" <[EMAIL PROTECTED]>
To: "Zlatko Matić" <[EMAIL PROTECTED]>
Cc:
Sent: Sunday, October 09, 2005 5:37 PM
Subject: Re: [GENERAL] pg_autovacuum
=?iso-8859-2?Q?Zlatko_Mati=E6?= <[EMAIL PROTECTED]> writes:
How to use pg_autovacuum ?
Read the README f
=?iso-8859-2?Q?Zlatko_Mati=E6?= <[EMAIL PROTECTED]> writes:
> How to use pg_autovacuum ?
Read the README file for it.
regards, tom lane
---(end of broadcast)---
TIP 6: explain analyze is your friend
How to use pg_autovacuum
?
p == pgman@candle.pha.pa.us writes:
p> Brandon Metcalf wrote:
...
p> > So, pg_autovacuum says it's going to sleep for 4886 seconds, but fires
p> > up again after just under 600 seconds.
p> >
p> > Can anyone explain what I'm seeing?
p> Yep, this was fixed in 8.0.X CVS in May, two days aft
Brandon Metcalf wrote:
> We're using pg_autovacuum with PostgreSQL 8.0.3 and it isn't sleeping
> as long as the claims it will. For example,
>
> ...
> [2005-09-20 15:40:23 CDT] INFO: last_analyze_count: 21735550;
> last_vacuum_count: 21735009
> [2005-09-20 15:40:23 CDT] INFO:
We're using pg_autovacuum with PostgreSQL 8.0.3 and it isn't sleeping
as long as the claims it will. For example,
...
[2005-09-20 15:40:23 CDT] INFO: last_analyze_count: 21735550;
last_vacuum_count: 21735009
[2005-09-20 15:40:23 CDT] INFO: analyze_threshold: 40676;
vacuum_
I verified that it was not doing anything by erasing the pg_statistics table
and it did not fill it within 24 hours. When I ran vacuum analyze manually it
filled it in.
I am using postgresql 8.03 on gentoo which was downloaded with portage and
included pg_autovacuum as part of the set up.
I wil
How do you know that it is not vacuuming or analyzing anything?
And which version of postgres did you build/acquire pg_autovacuum from?
It seems that in post-8.0 versions, there is almost no output by
default. You could try increasing the debug output using -d 1 or -d 2
on the command line t
I have pg_autovacuum running on my gentoo server, the same server with the
postgresql database.
ps shows that it is running and I have it start automatically with the
system. It is not vacuuming or analyzing the tables though.
Am I doing something wrong? Is there a better way to do this?
Thank You
I've tried to install pg_autovacuum as WindowsXP service but after intalling it properly, and when I try to initialize it, I get a 1053 error: "The service did not respond to the start or control request in a timely fashion".
The way that I've installed the service is:
pg_autovacuum -I -N .\winU
Hi folks,
8.0beta3 has pg_autovacuum included, when I want to run this as a Windows
service, it says you can use the -I and -R options.
When I do that and I specify a password with '-P' (uppercase) then in the
registry it's saved as '-p' (lowercase) in the service-commandline
(ImagePath).
Also i
I get this in the logs for every database open by pg_autovacuum:
Sep 1 14:02:45 cerberus pg_autovacuum: nss_ldap: could not connect to
any LDAP server as (null) - Can't contact LDAP server
This is produced by the bind_to() call in libnss-ldap. This is invoked
when /etc/nss_switch.conf specifies
I'm about to try to implement a simple pg_autovacuum script that can be
used in conjunction with or integrated entirely with the contrib
start-scripts for postgres. I just want to check that what I'm doing
has the appropriate sanity checks.
The behavior I'm considering is:
if pg_ctl status retu
On Tue, 2004-05-18 at 22:16, Bruce Momjian wrote:
> Brian Hirt wrote:
> > I've having a strange issue with pg_autovacuum. I have a table with
> > about 4 million rows in 20,000 pages. autovacuum likes to vacuum
> > and/or analyze it every 45 minutes or so, but it probably doesn't have
> > m
Matthew T. O'Connor wrote:
> > > this happens with other big tables too. the autovacuum is from 7.4.2,
> > > some information is below.
> >
> > Oh, 7.4.2. I know we have some known bug and are waiting on a patch for
> > it.
> >
> > Matthew, we need those fixes for pg_autovacuum soon.
>
> As
Have you tried installing gmake and using it instead of FreeBSD's
make? (not 100% sure, but it seems like that's the problem)
David Wheeler wrote:
4.8-STABLE FreeBSD 4.8-STABLE i386
sahlins# cd postgresql-7.4.2/contrib/pg_autovacuum
sahlins# make
"../../src/Makefile.global", line 38: Missing dep
Try gmake.
Regards.
En un mensaje anterior, David Wheeler escribió:
> 4.8-STABLE FreeBSD 4.8-STABLE i386
>
> sahlins# cd postgresql-7.4.2/contrib/pg_autovacuum
> sahlins# make
> "../../src/Makefile.global", line 38: Missing dependency operator
---(end of broadcast)-
Tom Lane wrote:
> Frank van Vugt <[EMAIL PROTECTED]> writes:
> > Did I miss this future necessity on the TODO-list ('cause I did check...) or
> > is it simply not on there (yet) ?
>
> It's not there; it should be. Something like
>
> * Need better (safer, less prone to unnecessary failures) sche
Frank van Vugt <[EMAIL PROTECTED]> writes:
> Did I miss this future necessity on the TODO-list ('cause I did check...) or
> is it simply not on there (yet) ?
It's not there; it should be. Something like
* Need better (safer, less prone to unnecessary failures) scheme for
ensuring CREATE DATAB
Hi,
Thanks Bruce ;-)
Tom Lane wrote:
> Sooner or later we'll have to face up to the conflict
Thanks Tom, I understand what's happening now.
Did I miss this future necessity on the TODO-list ('cause I did check...) or
is it simply not on there (yet) ?
I'm just being inquisitive, I understand
Adam Kavan wrote:
At 10:48 AM 9/4/03 -0400, Matthew T. O'Connor wrote:
On Thu, 2003-09-04 at 09:01, Jan Wieck wrote:
> Do the stats_* options appear twice in the config file? If that isn't
> the case, the only possible problem left I can think of is that you're
> running on a platform where no A
At 02:25 PM 9/4/03 -0400, Jan Wieck wrote:
>H ... would need to take a look at the code ... but a wild guess would
>be the communication between the backends and the collector daemon. I'm
>not sure if the UDP crap^H^H^H^Hstuff I used in there is IPV6 safe. What
>version of PostgreSQL was that?
At 09:41 PM 9/2/03 -0400, Matthew T. O'Connor wrote:
On Tue, 2003-09-02 at 20:40, Adam Kavan wrote:
> And there is the problem, all of the counts stay at 0 no matter what I do.
OK, so why is this happening... a bug in the stats system? Ignoring
pg_autovaccu, what numbers do you get from the stats
On Tue, 2003-09-02 at 20:40, Adam Kavan wrote:
> And there is the problem, all of the counts stay at 0 no matter what I do.
OK, so why is this happening... a bug in the stats system? Ignoring
pg_autovaccu, what numbers do you get from the stats system when you do
a:
SELECT relname,n_tup_ins,n_tu
First, I meant to ask for debug level 3, (-d3, not -d2) sorry Also,
are you sure that pg_autovacuum is connecting to the same database
cluster as your insert delete script?
I have attached a new log with a debug level of 3. And I am sure they are
connecting to the same cluster, I only have
On Tue, 2003-09-02 at 18:30, Adam Kavan wrote:
> Ok I ran pg_autovacuum using the supplied command line and have attached
> the resulting log. My script is just INSERT INTO "PointUsage"
> VALUES(DEFAULT,32,now(),1024); repeated several thousand times. I ran
> autovac, then my script, then veri
So you probabaly want to do somethign like this:
pg_autovacuum -d2 -s1 -S0 -v10 -V0 -a10 -A0 -L pg_autovacuum.out
this will set debug=2, sleep only 1 sec after each look, and perform
vacuums and analyzes after only 10 insert/update/delets and log it all to
pg_autovacuum.out
Run your update scrip
>
> What do you mean which options am I setting? I am using
>
> ./pg_autovacuum -U akavan -s30 -d3
Yeah, this is what I was looking for.
> I am using redhat 9 with gcc 3.2.2. And I will paste some output from
> debug level 2 at the end of this post. During the run I inserted 10523
> lines int
On Fri, 2003-08-29 at 17:21, Adam Kavan wrote:
> I decided to try pg_autovacuum and am having a problem.
FYI, I just downloaded beta2 and compiled it on RH9 and pg_autovacuum
works fine.
---(end of broadcast)---
TIP 3: if posting/reading through
On Fri, 2003-08-29 at 17:21, Adam Kavan wrote:
> I decided to try pg_autovacuum and am having a problem. It never analyzes
> or vacuums. I looked at the code and had it display
>
> printf("%s,%s,%s\n",PQgetvalue(res, j, PQfnumber(res,
> "n_tup_ins")),PQgetvalue(res, j, PQfnumber(res,
> "n_tup
59 matches
Mail list logo
