From: | "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | <pgsql-hackers(at)postgreSQL(dot)org>, "Cyrus Rahman" <cr(at)photox(dot)jcmax(dot)com> |
Subject: | RE: [HACKERS] File descriptor leakage? |
Date: | 1999-08-31 04:49:32 |
Message-ID: | 002701bef36c$37985420$2801007e@cadzone.tpf.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> -----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;
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Lockhart | 1999-08-31 05:11:06 | Re: [COMMITTERS] pgsql/src/include/parser (parse_node.h parse_oper.h) |
Previous Message | Thomas Lockhart | 1999-08-31 04:09:37 | Re: [HACKERS] Postgres' lexer |