From: | Rick Gigger <rick(at)alpinenetworking(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Working happily on 8.1 (Was: panic on 7.3) |
Date: | 2006-01-21 18:15:51 |
Message-ID: | 21CB36E4-9D72-4A21-A5CD-28F5668E6FE9@alpinenetworking.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Rick Gigger <rick(at)alpinenetworking(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Rod Taylor | 2006-01-21 18:28:10 | Re: Commands per transaction |
Previous Message | Heikki Linnakangas | 2006-01-21 18:12:23 | Re: Commands per transaction |