RE: [HACKERS] File descriptor leakage? - Mailing list pgsql-hackers

> -----Original Message-----
> From: owner-pgsql-hackers@postgreSQL.org
> [mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Tom Lane
> Sent: Tuesday, August 31, 1999 10:50 AM
> To: Cyrus Rahman
> Cc: pgsql-hackers@postgreSQL.org
> Subject: Re: [HACKERS] File descriptor leakage? 
> 
> 
> Cyrus Rahman <cr@photox.jcmax.com> writes:
> > Has anyone seen a problem with postgresql-6.5.1 leaking file
> > descriptors?
> 
> That's interesting, I thought I'd fixed all the file-descriptor-leakage
> problems.  Guess not :-(
> 

The following may be one of the cause.

> -----Original Message-----
> From: owner-pgsql-hackers@postgreSQL.org
> [mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Vadim Mikheev
> Sent: Monday, June 07, 1999 7:49 PM
> To: Hiroshi Inoue
> Cc: The Hermit Hacker; pgsql-hackers@postgreSQL.org
> Subject: Re: [HACKERS] postgresql-v6.5beta2.tar.gz ...
>

[snip] 

> 
> 1. bug in cache invalidation code: when we invalidate relcache
>    we forget to free MdfdVec in md.c!
> 
>    Vacuum invalidates a relation tuple in pg_class and concurrent
>    xactions invalidate corresponding relcache entry, but don't
>    free MdfdVec and so allocate new one for the same relation
>    more and more. Each MdfdVed requires own fd.c:Vfd entry -> below
> 
> 2. fd.c:pg_nofile()->sysconf(_SC_OPEN_MAX) returns in FreeBSD 
>    near total number of files that can be opened in system
>    (by _all_ users/procs). With total number of opened files
>    ~ 2000 I can run your test with 10-20 simultaneous
>    xactions for very short time, -:)
> 
>    Should we limit fd.c:no_files to ~ 256?
>    This is port-specific, of course...

I posted a patch about a month ago([HACKERS] double opens).
But yutaka tanida [yutaka@marin.or.jp] reported a bug caused 
by the patch. I found it's because of calling smgrclose() after 
smgrclose()/smgrunlink() for the same relation.

It seems my old patch has not been appiled yet.
Here is a new patch.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

*** utils/cache/relcache.c.orig    Mon Jul 26 12:45:15 1999
--- utils/cache/relcache.c    Mon Aug 30 15:37:10 1999
***************
*** 1259,1264 ****
--- 1259,1265 ----          oldcxt = MemoryContextSwitchTo((MemoryContext) CacheCxt); 
+         smgrclose(DEFAULT_SMGR, relation);         RelationCacheDelete(relation);
FreeTupleDesc(relation->rd_att);
*** storage/smgr/md.c.orig    Mon Jul 26 12:45:09 1999
--- storage/smgr/md.c    Tue Aug 31 13:44:28 1999
***************
*** 190,195 ****
--- 190,197 ----      /* finally, clean out the mdfd vector */     fd = RelationGetFile(reln);
+     if (fd < 0)
+         return SM_SUCCESS;     Md_fdvec[fd].mdfd_flags = (uint16) 0;      oldcxt = MemoryContextSwitchTo(MdCxt);
***************
*** 211,216 ****
--- 213,219 ----     MemoryContextSwitchTo(oldcxt);      _fdvec_free(fd);
+     reln->rd_fd = -1;      return SM_SUCCESS; }
***************
*** 319,324 ****
--- 322,329 ----     MemoryContext oldcxt;      fd = RelationGetFile(reln);
+     if (fd < 0)
+         return SM_SUCCESS;      oldcxt = MemoryContextSwitchTo(MdCxt); #ifndef LET_OS_MANAGE_FILESIZE
***************
*** 370,375 ****
--- 375,381 ----     MemoryContextSwitchTo(oldcxt);      _fdvec_free(fd);
+     reln->rd_fd = -1;      return SM_SUCCESS; }
***************
*** 895,900 ****
--- 901,907 ---- {      Assert(Md_Free < 0 || Md_fdvec[Md_Free].mdfd_flags == MDFD_FREE);
+     Assert(Md_fdvec[fdvec].mdfd_flags != MDFD_FREE);     Md_fdvec[fdvec].mdfd_nextFree = Md_Free;
Md_fdvec[fdvec].mdfd_flags= MDFD_FREE;     Md_Free = fdvec;