Re: Working happily on 8.1 (Was: panic on 7.3)

Поиск
Список
Период
Сортировка
От Rick Gigger
Тема Re: Working happily on 8.1 (Was: panic on 7.3)
Дата
Msg-id 21CB36E4-9D72-4A21-A5CD-28F5668E6FE9@alpinenetworking.com
обсуждение исходный текст
Ответ на Re: Working happily on 8.1 (Was: panic on 7.3)  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Working happily on 8.1 (Was: panic on 7.3)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
> Rick Gigger <rick@alpinenetworking.com> writes:
>> 2) I didn't touch the Vacuum delay, background writer or autovacuum
>> settings because I wasn't familiar enough with them.  Are the default
>> values very restricting?
>
> By default, autovacuum isn't even turned on --- you have to enable it
> and also stats_row_level if you want to use autovac.  I don't have
> enough experience with it to say whether the other settings are
> adequate.

Yes, I realized this not long after I started things up, so I will  
have to wait till a time when I can restart postgres to try it out.   
For now I have come up with something that I think will work fine.   
Vacuum seems to be about a million times faster now due to a number  
of factors.  I am going to keep a close eye on the sessions table  
making sure that it can't start getting bloated again and I think  
I'll be ok.   It's a saturday though so we'll really see how it holds  
up on monday.

>
>> 3) Several times there were backends  running that were just bringing
>> down the system.  Is there a way to signal a single backend to die
>> without restarting the whole db server?
>
> SIGINT (ie query cancel) is safe enough.  If that doesn't work  
> within a
> few seconds, try SIGTERM (there is controversy over how safe that is,
> but people do use it).

Thanks again!

Rick


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Commands per transaction
Следующее
От: Rod Taylor
Дата:
Сообщение: Re: Commands per transaction