From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | DHSC Webmaster <webmaster(at)dhs-club(dot)com> |
Cc: | pgsql-admin(at)postgresql(dot)org |
Subject: | Re: PG 7.0.3 & RH 7 IPC problems? |
Date: | 2001-03-29 19:30:52 |
Message-ID: | 23644.985894252@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
DHSC Webmaster <webmaster(at)dhs-club(dot)com> writes:
> [root(at)atl01371 linux]# ipcs
> ------ Shared Memory Segments --------
> key shmid owner perms bytes nattch status
> 0x0052e2ca 36864 postgres 700 144 5
> 0x0052e2c1 26625 postgres 600 1104896 5
> 0x0052e2c7 37890 postgres 600 66060 5
> ------ Semaphore Arrays --------
> key semid owner perms nsems status
> 0x0052e2ce 6144 postgres 600 16
> 0x0052e2cf 6145 postgres 600 16
> ------ Message Queues --------
> key msqid owner perms used-bytes messages
> These values don't seem to change from one moment to the next although
> there are of course varying numbers of backends running at any given
> moment.
These objects are created by the postmaster and persist as long as the
postmaster does. They *should* go away when you shut down the
postmaster, but perhaps they didn't for some reason.
Anyway, I suggest (a) shut down postmaster, (b) use ipcs to make sure
there are no postgres shmem or sema objects (delete 'em with ipcrm if
necessary), and (c) try to start postmaster with new -B/-N values.
If step (c) fails when there are no pre-existing objects, then it must
be that you have not managed to increase the kernel's limits on shared
memory. The exact incantations needed to accomplish that trick vary
across systems, so I can't offer a lot of help there.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Stefan Huber | 2001-03-29 19:39:50 | Re: How to place a table on a separate partition? |
Previous Message | Rodin A. Porrata | 2001-03-29 18:51:53 | How to place a table on a separate partition? |