| 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: | Whole Thread | Raw Message | 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. |