From: | Jeff Amiel <jamiel(at)istreamimaging(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jeff Amiel <becauseimjeff(at)yahoo(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: 3rd time is a charm.....right sibling is not next child crash. |
Date: | 2010-06-08 18:04:38 |
Message-ID: | C833F066.4B4C8%jamiel@istreamimaging.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
On 6/8/10 12:56 PM, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Jeff Amiel <jamiel(at)istreamimaging(dot)com> writes:
>> On a side note, I am 100% sure that autovacuum was disabled when I brought
>> the database back up after the core dump(s). However, minutes after
>> restarting, some of my larger tables started getting vacuumed by pgsql user.
>> Any way that a vacuum would kick off for a particular table (or series of
>> tables) even when autovacuum was off in the postgresql.conf?
>
> Anti-transaction-wraparound vacuums, perhaps?
I would hope not. :)
This is postgres 8.2.X. Autovacuum has been enabled forever (seemingly with
no errors)
Anything I can look for ? (I searched the logs for references to "must be
vacuumed within" but found nothing....)
SELECT datname, age(datfrozenxid) FROM pg_database;
postgres 178649703
prod 204588751
template1 178653277
template0 178653131
From | Date | Subject | |
---|---|---|---|
Next Message | Kalai R | 2010-06-08 18:08:50 | Query process is very slow |
Previous Message | uaca man | 2010-06-08 18:01:16 | Re: Queues Problem |
From | Date | Subject | |
---|---|---|---|
Next Message | Jaime Casanova | 2010-06-08 18:15:41 | Re: 3rd time is a charm.....right sibling is not next child crash. |
Previous Message | Tom Lane | 2010-06-08 17:56:10 | Re: 3rd time is a charm.....right sibling is not next child crash. |