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

From: Greg Sabino Mullane <greg(at)endpoint(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Backends stalled in 'startup' state: index corruption
Date: 2012-05-25 22:08:19
Message-ID: 20120525220819.GB10277@tinybird.home
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> Yeah, this is proof that what it was doing is the same as what we saw in
> Jeff's backtrace, ie loading up the system catalog relcache entries the
> hard way via seqscans on the core catalogs. So the question to be
> answered is why that's suddenly a big performance bottleneck. It's not
> a cheap operation of course (that's why we cache the results ;-)) but
> it shouldn't take minutes either. And, because they are seqscans, it
> doesn't seem like messed-up indexes should matter.

FWIW, this appeared to be an all-or-nothing event: either every new backend
was suffering through this, or none were. They all seemed to clear up
at the same time as well.

> The theory I have in mind about Jeff's case is that it was basically an
> I/O storm, but it's not clear whether the same explanation works for
> your case. There may be some other contributing factor that we haven't
> identified yet.

Let me know if you think of anything particular I can test while it is
happening again. I'll try to arrange a (netapp) snapshot the next time
it happens as well (this system is too busy and too large to do anything
else).

--
Greg Sabino Mullane greg(at)endpoint(dot)com
End Point Corporation
PGP Key: 0x14964AC8

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Sergey Koposov 2012-05-25 22:53:36 Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile
Previous Message Jim Nasby 2012-05-25 21:57:57 Re: heap metapages