Thanks..i will stick to vacuumdb in 8.1 (which works fine..just takes
a couple of days to finish)
Migration is an option..but our databases are enormous..(> 800G) and
we have several of them
On Wed, Nov 4, 2009 at 12:00 PM, Alvaro Herrera
wrote:
> Anj Adu escribió:
>> If I were to use autovacuum
Anj Adu escribió:
> If I were to use autovacuum on 8.1 , and If I specify the "ignore'
> tables in pg_autovacuum,
>
> 1. will the XID wraparound counter be reset after autovacuum finishes
No.
I think you really need to get off 8.1.
--
Alvaro Herrerahttp://www.Co
If I were to use autovacuum on 8.1 , and If I specify the "ignore'
tables in pg_autovacuum,
1. will the XID wraparound counter be reset after autovacuum finishes
2. If some of the ignore tables are never dropped or deleted in the
future...how do the transaction semantics work with the rows in thes
Anj Adu escribió:
> My goal is to reset the XID wraparound counter by performing vacuumdb
> (autovacuum is not an option for my for various reasons)
Note that if you are on 8.1 (I can't recall) you need to vacuum the
whole database in a single command for Xid wraparound. Only on 8.2 and
higher yo
Anj Adu escribió:
> Does vacuumdb read pg_autovacuum ?
>
> If not, can I specify multiple comma-separated tables to pass as
> arguments to vacuumdb ? The list of tables that need to be vacuumed
> is a constant and hence easier to manage the vacuuming process.
No, but you can write a simple scrip
le you need to vacuum?
>
>
> -Original Message-
> From: pgsql-admin-ow...@postgresql.org on behalf of Anj Adu
> Sent: Sun 11/1/2009 8:03 AM
> To: Alvaro Herrera
> Cc: pgsql-admin@postgresql.org
> Subject: Re: [ADMIN] pg_autovacuum entries
>
> Does vacuumdb re
t: Re: [ADMIN] pg_autovacuum entries
Does vacuumdb read pg_autovacuum ?
If not, can I specify multiple comma-separated tables to pass as
arguments to vacuumdb ? The list of tables that need to be vacuumed
is a constant and hence easier to manage the vacuuming process.
On Fri, Oct 30, 2009 at 3:
Does vacuumdb read pg_autovacuum ?
If not, can I specify multiple comma-separated tables to pass as
arguments to vacuumdb ? The list of tables that need to be vacuumed
is a constant and hence easier to manage the vacuuming process.
On Fri, Oct 30, 2009 at 3:04 PM, Alvaro Herrera
wrote:
> Anj Ad
Anj Adu escribió:
> Is there a way to create an entry for a table that does not exist yet?
No, you will have to have "INSERT INTO pg_autovacuum" statements
alongside your table creation. I don't see that this is a lot of
trouble though, you can simply do
CREATE TABLE whatever ( ... );
INSERT IN
On 1/11/06, Eran L <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I must be missing some obvious and trivial thing, since I simply can
> get pg_autovacuum to work.
>
> Im working on FC4, postgresql 8.0.6.
> In the "postgresql.conf" file, I've set:
>
> stats_row_level = true
>
> I've restarted the postmaster.
Eran L <[EMAIL PROTECTED]> writes:
> Im working on FC4, postgresql 8.0.6.
> In the "postgresql.conf" file, I've set:
> stats_row_level = true
> I've restarted the postmaster. Yet, when I'm running pg_autovacuum, it says:
> [2006-01-11 12:11:07 IST] ERROR: GUC variable stats_row_level must be
A while back, I wrote this:
http://www.sitening.com/auto_pg_autovacuum
While not exactly an init script, it sanely avoids multiply starting
pg_autovacuum.
Then I did this:
http://www.sitening.com/pgautovacuum
which is a proper init script.
Thanks for prompting me to post it! Now there are
As Alvaro already mentioned this is fixed in 8.1 because it was
integrated into the backend and benifits from the logging features that
backend already has developed.
As for the 7.4.x & 8.0.x versions of contrib autovacuum, I don't think
there are any plans for improving it. Also, added it to
Ameet Kini wrote:
>
> Any plans of incorporating it into a future release? How do people
> currently deal with this problem? I wonder if this is fixed in the
> pg_autovacuum distributed with v8.1
8.1 does not have this problem, because autovacuum got integrated into
the server proper and no longe
Most people running Linux would add it to their logrotate.conf or other log
management methods.
On Mon, 12 Dec 2005, Ameet Kini wrote:
Any plans of incorporating it into a future release? How do people
currently deal with this problem? I wonder if this is fixed in the
pg_autovacuum distribut
Any plans of incorporating it into a future release? How do people
currently deal with this problem? I wonder if this is fixed in the
pg_autovacuum distributed with v8.1
On Sun, 11 Dec 2005, Matthew T. O'Connor wrote:
> Unfortunately, you are correct, there is no way to tell
> contrib/autovacu
Unfortunately, you are correct, there is no way to tell
contrib/autovacuum to rotate it's logs.
Ameet Kini wrote:
Hello,
I'm using postgresql 8.0 and am using contrib/pg_autovacuum. Is there a
way to tell pg_autovacuum to rotate the log that it generates after
it reaches a particular size? Fro
A while back, I wrote this:
http://www.sitening.com/auto_pg_autovacuum
While not exactly an init script, it sanely avoids multiply starting
pg_autovacuum.
Then I did this:
http://www.sitening.com/pgautovacuum
which is a proper init script.
Thanks for prompting me to post it! Now there are some op
The problem was in my resolve.conf, the nameserver I've set is my datacenter
provider who have localhost.provider.net point to 127.0.0.1 and postmaster
couldn't bind to that host. For whatever reason. It does not check /etc/hosts
too so I'll play with it on Mondey.
На 29.10.2004 18:20 вие напис
Hi Ivan,
I had the same experience as you. I swear I did all the things required.
Eventually it started working with enough postmaster restarts and fiddling
with the files. I'm sorry I can't be more helpful, cause I was never quite
sure why it finally decided to start working...
Keep fiddling a
[EMAIL PROTECTED] wrote:
I run pg_autovacuum:
./pg_autovacuum -D
but then I cannot find pg_autovacuum.log file.
Where shoud I look for it?
Try:
./pg_autovacuum -D -L
Kind regards,
--
Cris Carampa (spamto:[EMAIL PROTECTED])
I got some John Coltrane on the stereo baby make it feel all right
I got s
On Fri, 2004-07-23 at 04:58, Mario Soto wrote:
> Hi i have a postgresql 7.4 in redhat 9
>
> in postgresql.con
> stats_row_level = true
>
> but whe excecute ./pg_autovacuum say
>
> [2004-07-22 11:53:25 PM] Error: GUC variable stats_row_level must be enabled.
Have you restarted/signalled the pos
On Mon, 2003-08-04 at 10:15, Mendola Gaetano wrote:
> Hi,
> I used to install postgres 7.3.3 from RPM,
> today I needed to take a look at pg_utovacuum but I didn't
> find it ?
>
> Should I download it somewhere else ?
>
you'd have to check it out from CVS and then compile it into a 7.3 cvs
pu
23 matches
Mail list logo
