Re: Backends stalled in 'startup' state: index corruption

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Sabino Mullane <greg(at)endpoint(dot)com>
Cc: Jeff Frost <jeff(at)pgexperts(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Backends stalled in 'startup' state: index corruption
Date: 2012-05-28 15:16:24
Message-ID: 5839.1338218184@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greg Sabino Mullane <greg(at)endpoint(dot)com> writes:
> On Sun, May 27, 2012 at 05:44:15PM -0700, Jeff Frost wrote:
>> On May 27, 2012, at 12:53 PM, Tom Lane wrote:
>>> occurring, they'd take long enough to expose the process to sinval
>>> overrun even with not-very-high DDL rates.

>> As it turns out, there are quite a few temporary tables created.

> For the record, same here. We do *lots* of DDL (hence the cronjobs
> to vac/reindex system catalogs).

I wonder if it could've been something like transient problem with
a cronjob leading to massive bloat of pg_attribute, eventually
triggering the syncscan issue, then fixed by a successful VAC FULL
before we thought to look closely at the table size. The syncscan
issue definitely was there in 8.3.5, it's only the question of
pg_attribute size that made me doubt it was happening for you.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dimitri Fontaine 2012-05-28 15:39:41 Re: How could we make it simple to access the log as a table?
Previous Message Andres Freund 2012-05-28 14:35:32 Re: WalSndWakeup() and synchronous_commit=off