On 6/8/10 11:23 AM, "Tom Lane" <tgl@xxxxxxxxxxxxx> wrote: > In your original report you mentioned that the next autovacuum attempt > on the same table succeeded without incident. Has that been true each > time? I wonder whether this is some transient state, rather than actual > corruption that you need to REINDEX to recover from. > I didn't waste time during this event and reindexed as quick as I could. I will note, however, that these indexes (specifically the one that generated the error) were in use (successfully) AFTER the event BEFORE the reindex by the slony triggers (by virtue of inserts into the log tables and such) even though I stopped autovacuum and slon daemon. Not reads, obviously...just inserts/updates. If nobody else has seen/is seeing this, I will chalk this whole scenario up to oddball SAN issues (we've logged many a write/read error over the year(s) causing corruption on these heavily manipulated indexes. I'll be glad to move to my attached storage as quickly as possible. 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? My only manual vacuum process is kicked off late at night, so this was not it. Also....before I had a chance to disable the slon daemon I also noticed other slony tables being vacuum analyzed (even though autovacuum was off) ....Does Slony manage it's own vacuuming separate from postgres' autovacuum? -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
