Re: 9.1.3 backends getting stuck in 'startup'
От | Tom Lane |
---|---|
Тема | Re: 9.1.3 backends getting stuck in 'startup' |
Дата | |
Msg-id | 2784.1337898946@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: 9.1.3 backends getting stuck in 'startup' (Jeff Frost <jeff@pgexperts.com>) |
Ответы |
Re: 9.1.3 backends getting stuck in 'startup'
|
Список | pgsql-bugs |
Jeff Frost <jeff@pgexperts.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 tobe 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
В списке pgsql-bugs по дате отправления: