RE: [HACKERS] File descriptor leakage?

> -----Original Message-----
> From: owner-pgsql-hackers(at)postgreSQL(dot)org
> [mailto:owner-pgsql-hackers(at)postgreSQL(dot)org]On Behalf Of Tom Lane
> Sent: Tuesday, August 31, 1999 10:50 AM
> To: Cyrus Rahman
> Cc: pgsql-hackers(at)postgreSQL(dot)org
> Subject: Re: [HACKERS] File descriptor leakage?
>
>
> Cyrus Rahman <cr(at)photox(dot)jcmax(dot)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(at)postgreSQL(dot)org
> [mailto:owner-pgsql-hackers(at)postgreSQL(dot)org]On Behalf Of Vadim Mikheev
> Sent: Monday, June 07, 1999 7:49 PM
> To: Hiroshi Inoue
> Cc: The Hermit Hacker; pgsql-hackers(at)postgreSQL(dot)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(at)marin(dot)or(dot)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(at)tpf(dot)co(dot)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;