| From: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> |
|---|---|
| To: | Martijn van Oosterhout <kleptog(at)svana(dot)org>, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Ben Chobot <bench(at)silentmedia(dot)com>, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: vacuum issues under load? |
| Date: | 2010-01-19 01:35:11 |
| Message-ID: | dcc563d11001181735j24e9c6b0r9d6c09bbe0c5462b@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Mon, Jan 18, 2010 at 12:28 AM, Martijn van Oosterhout
<kleptog(at)svana(dot)org> wrote:
> On Fri, Jan 15, 2010 at 08:41:38AM -0700, Scott Marlowe wrote:
>> With slony 2.0.3 or so, I had occasional complete lockups of my
>> database that I didn't have time to troubleshoot as it was a live
>> cluster and I had to restart slony and the databases to get them back
>> up and running.
>
> With slony 2.0.2 I had similar problems. A CREATE INDEX on the slave
> caused slony on the slave to block while inserting into the table which
> eventually blocked the server during the log switch (TRUNCATE) which
> eventually blocked everything else.
You could have used create index interactively.
> It occurs to me that the slony daemon should be able to get the
> TRUNCATE command to abort if it takes too long.
No, I don't want it stopping my truncates.
The problem I ran into was on a db with no creating indexes, no
truncates nothing like that going on. It runs fine for a week or two,
then hangs hard. No updates, no selects, nothing works. There are no
locks in the way that I can see, just hung database.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Scott Marlowe | 2010-01-19 01:36:17 | Re: vacuum issues under load? |
| Previous Message | Scott Marlowe | 2010-01-19 01:29:33 | Re: number of page slots needed (1576544) exceeds max_fsm_pages (204800)] |