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
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
> 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
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
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
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
> 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
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
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:
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
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
44 matches
Mail list logo
