Thread: shared memory leak in 7.0.2?

All,
  i've been running 7.0.2 for the last month or so, and I've had to reboot my
redhat linux box twice to clear up a shared memory leak issue. Essentially
with the DB running for about 2weeks with large amounts of usage, eventually
the Os runs out of shared memory and the db crashes and fails to restart. The
only way to get the db back online is to reboot.

  Has anyone seen this? Or does anyone have any suggestions on how to fix it?

BTW. Here is my startup line for the postgres daemon.

su -l postgres -c 'exec /usr/local/pgsql/bin/postmaster -B 384  -D/usr/local/pgsql/data -i -S -o -F


Pierre

pierre@kahuna.versions.com writes:
>   i've been running 7.0.2 for the last month or so, and I've had to
> reboot my redhat linux box twice to clear up a shared memory leak
> issue. Essentially with the DB running for about 2weeks with large
> amounts of usage, eventually the Os runs out of shared memory and the
> db crashes and fails to restart. The only way to get the db back
> online is to reboot.

I haven't seen this reported before.  Are you sure Postgres deserves
the blame, rather than some other package?  Postgres' use of shared
memory is fixed for the life of a postmaster, so unless you're
constantly restarting the postmaster I don't see how we could be leaking
shmem.

However, rather than speculate, let's get some hard facts.  Try using
"ipcs -m -a" to keep track of shared mem allocations, and see what usage
is creeping up over time.
        regards, tom lane

Pierre Padovani <ppadovan@tivoli.com> writes:
>   Here is the current output of that ipc command:

Looks pretty reasonable --- the three shmem segments look to be about
what postgres should be using (I take it you've got -B set to 350 or
so).

>  If postgres were to crash for some reason. Would the shared memory be
> left in never never land?

In theory the postmaster should release those segments when it's shut
down, or failing that reuse 'em when it's restarted.  We have heard
occasional reports of this failing to happen on some platforms; but
again, unless you're restarting the postmaster on a regular basis that
doesn't seem like it'd be the issue.  Anyway, keep an eye on things with
ipcs and we'll see what's going on...
        regards, tom lane

Tom, Thanks for that command. I never knew that existed. The only reason I
blame postgres at this point, is that the only thing that has changed on
this machine in the past month was upgrading postgres to 7.0.2 as well
as upgrading perl.  Of the two perl is used not nearyl as much as
postgres.
 Here is the current output of that ipc command:

[root@kahuna pierre]# ipcs -m -a

------ Shared Memory Segments --------
key        shmid     owner     perms     bytes     nattch    status      
0x0052e2ca 0         postgres  700       144       2                     
0x0052e2c1 1         postgres  600       3769344   2                     
0x0052e2c7 2         postgres  600       66060     2                     
0x00000000 3         llee      600       46084     6         dest        
0x00000000 4         www       600       46084     11        dest        

------ Semaphore Arrays --------
key       semid     owner     perms     nsems     status      
0x0052e2ce 0         postgres  600       16        
0x0052e2cf 1         postgres  600       16        

------ Message Queues --------
key       msqid     owner     perms     used-bytes  messages    
0x00000000 0         root      700       0           0           

If postgres were to crash for some reason. Would the shared memory be
left in never never land? If this were the case, and I'm using most if
not all of the available shared memory on startup of postgres, then this
would bring about the problems I'm seeing. Does this make sense?
Pierre

Tom Lane wrote:
> 
> pierre@kahuna.versions.com writes:
> >   i've been running 7.0.2 for the last month or so, and I've had to
> > reboot my redhat linux box twice to clear up a shared memory leak
> > issue. Essentially with the DB running for about 2weeks with large
> > amounts of usage, eventually the Os runs out of shared memory and the
> > db crashes and fails to restart. The only way to get the db back
> > online is to reboot.
> 
> I haven't seen this reported before.  Are you sure Postgres deserves
> the blame, rather than some other package?  Postgres' use of shared
> memory is fixed for the life of a postmaster, so unless you're
> constantly restarting the postmaster I don't see how we could be leaking
> shmem.
> 
> However, rather than speculate, let's get some hard facts.  Try using
> "ipcs -m -a" to keep track of shared mem allocations, and see what usage
> is creeping up over time.
> 
>                         regards, tom lane

OK, I before any starts on my about backups...I have one a week
old, but I want to fix this the right way! (and I want this past
week's worth of data.

What happened:

o downloaded ip and macaddr type programs written by Paul Vixie
et al., scrapped the ip stuff, and compiled the macaddr stuff.
Ran the included sql script to load the "mac.so" file, create
the custom macaddr type in and out functions, etc.  At this
point everything is good.

o downloaded latest copy of IEEE MAC Address to Vendor list.
Updated the mac.h file and recompiled the module.

o Dropped all the functions and the types.

o Re-ran the SQL script to create the handler, type, functions, etc
after putting the new mac.so module in the proper path.

o All hell breaks loose:
    o use functions are missing from pgaccess
    o pg_dump dies with invalid OID number(s)
    o multiple instances of macaddr definitions in pg_proc...

o Tried to fix this with a reindex, but I was told that I had
to drop the DB into single user mode, I tried this but the directions
don't jive with pg_ctl nor with postmaster.  I can't figure how to
get to single mode....

Questions:

1. How do I to get the DB into single user mode?

2. How can I fix this problem?


TIA.

tim
dirac@applink.net