From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jeff Frost <jeff(at)pgexperts(dot)com> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: 9.1.3 backends getting stuck in 'startup' |
Date: | 2012-05-24 22:35:46 |
Message-ID: | 2784.1337898946@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Jeff Frost <jeff(at)pgexperts(dot)com> writes:
> On May 24, 2012, at 3:13 PM, Tom Lane wrote:
>> Huh. A bit bigger, but not by that much. It doesn't seem like this
>> would be enough to make seqscan performance fall off a cliff, as it
>> apparently did. Unless maybe the slightly-bloated catalogs were just a
>> bit too large to fit in RAM, and so the repeated seqscans went from
>> finding all their data in kernel disk buffers to finding none of it?
> Seems unlikely.
> Server has 128GB of RAM.
Hm ... sure seems like that ought to be enough ;-), even with a near-2GB
pg_attribute table. What's your shared_buffers setting?
> BTW, when I connected to it this time, I had a really long time before my psql was able to send a query, so it seems to be still broken at least.
Yeah, I was afraid that re-initdb would be at best a temporary solution.
It would probably be useful to confirm the theory that relcache rebuild
is what makes it stall. You should be able to manually remove the
pg_internal.init file in the database's directory; then connect with
psql, and time how long it takes before the pg_internal.init file
reappears.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Frost | 2012-05-24 22:39:34 | Re: 9.1.3 backends getting stuck in 'startup' |
Previous Message | Jeff Frost | 2012-05-24 22:25:37 | Re: 9.1.3 backends getting stuck in 'startup' |