Re: Numerous postmaster processes after upgrading to 7.2.3

From: Ericson Smith <eric(at)did-it(dot)com>
To: Postgresql General <pgsql-general(at)postgresql(dot)org>
Subject: Re: Numerous postmaster processes after upgrading to 7.2.3
Date: 2002-10-21 16:21:59
Message-ID: 1035217319.32138.22.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Ok, I found the problem.
Doing an analyze on the database solved it. Apparently the planner did
not have much to go on directly after the restore. Silly me.

- Ericson Smith
eric(at)did-it(dot)com

On Mon, 2002-10-21 at 12:11, Ericson Smith wrote:
> Hi all,
>
> Today we upgraded to ver 7.2.3 from 7.2.2.
> I also dumped and restored the data before doing so, just in case :-)
>
> I've noticed a few things...
>
> 1. The database server load is much higher ~ 2.00 instead of ~ 0.30
> 2. Many more postmasters are running ~ 20 instead of ~ 5
>
> Some changes I made were:
>
> 1. Moved the log directories pg_xlog and pg_clog over to their own
> drives (made symbolic links from there)
>
> 2. Changed the amount of shared memory from 350MB to 320MB
>
> What would account for the new load? Queries seem to be taking much
> longer. We have logs of RAM on the server 6GB and are running SCSI Raid
> on the system. This is also a Dual Xeon system (2.4GHz).
>
> Some more background...
> 1. The database locked up last night (each postgres process was in
> Uninterruptible Sleep)
> 2. We had to cycle the power on the server to get it going again.
>
> Any help/insights would be greatly appreciated.
>
> - Ericson Smith
> eric(at)did-it(dot)com
> http://www.did-it.com
>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Doug McNaught 2002-10-21 16:27:20 Re: [GENERAL] Security implications of (plpgsql) functions
Previous Message Joe Conway 2002-10-21 16:20:36 Re: [GENERAL] Security implications of (plpgsql) functions