RE: [HACKERS] Open 6.5 items - Mailing list pgsql-hackers
From | Hiroshi Inoue |
---|---|
Subject | RE: [HACKERS] Open 6.5 items |
Date | |
Msg-id | 000b01bea04a$ba0582e0$2801007e@cadzone.tpf.co.jp Whole thread Raw |
Responses |
Re: [HACKERS] Open 6.5 items
|
List | pgsql-hackers |
> -----Original Message----- > From: owner-pgsql-hackers@postgreSQL.org > [mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Bruce Momjian > Sent: Monday, May 17, 1999 3:40 PM > To: Ole Gjerde > Cc: PostgreSQL-development > Subject: Re: [HACKERS] Open 6.5 items > > > > List updated. Patch applied. Thanks. > I have 2 questions about the patch. 1.The following code exists in mdunlink(). Something like this isn't necessary ? /* finally, clean out the mdfd vector*/ fd = RelationGetFile(reln); Md_fdvec[fd].mdfd_flags = (uint16) 0; oldcxt = MemoryContextSwitchTo(MdCxt); #ifndef LET_OS_MANAGE_FILESIZE for (v = &Md_fdvec[fd]; v != (MdfdVec *) NULL;) { FileUnlink(v->mdfd_vfd); ov = v; v = v->mdfd_chain; if (ov != &Md_fdvec[fd]) pfree(ov); } Md_fdvec[fd].mdfd_chain = (MdfdVec *) NULL; #else v = &Md_fdvec[fd]; if (v != (MdfdVec *) NULL) FileUnlink(v->mdfd_vfd); #endif 2.Even if such code something like above is added,other transactions may hold valid file descriptors for FileName Unlink()edsegment files. Isn't it the problem ? I'm afraid different transactions write to different i-nodes which have or had a same segment file name. It seems moresecure to truncate segment files to 0 length than unlinking those files. But I'm not sure it works fine. Thanks. Hiroshi Inoue Inoue@tpf.co.jp > > > On Sun, 16 May 1999, Bruce Momjian wrote: [snip] > > > > > Vacuum of tables >2 gigs - NOTICE: Can't truncate > multi-segments relation > > > > This is actually more of a fundamental problem with mdtruncate. > It looks > > like someone just didn't add support for multiple segments for > truncation. > > > > The following patch seems to do the right thing, for me at least. > > It passed my tests, my data looks right(no data that shouldn't be in > > there) and regression is ok. > > > > Ole Gjerde > > > > --- src/backend/storage/smgr/md.c 1999/04/05 22:25:11 1.42 > > +++ src/backend/storage/smgr/md.c 1999/05/17 06:23:23 > > @@ -711,15 +711,26 @@ > > MdfdVec *v; > > > > #ifndef LET_OS_MANAGE_FILESIZE > > - int curnblk; > > + int curnblk, > > + i, > > + oldsegno, > > + newsegno; > > + char fname[NAMEDATALEN]; > > + char tname[NAMEDATALEN + 10]; > > > > curnblk = mdnblocks(reln); > > - if (curnblk / RELSEG_SIZE > 0) > > - { > > - elog(NOTICE, "Can't truncate multi-segments relation %s", > > - reln->rd_rel->relname.data); > > - return curnblk; > > - } > > + oldsegno = curnblk / RELSEG_SIZE; > > + newsegno = nblocks / RELSEG_SIZE; > > + > > + StrNCpy(fname, RelationGetRelationName(reln)->data, NAMEDATALEN); > > + > > + if (newsegno < oldsegno) { > > + for (i = (newsegno + 1);; i++) { > > + sprintf(tname, "%s.%d", fname, i); > > + if (FileNameUnlink(tname) < 0) > > + break; > > + } > > + } > > #endif > > > > fd = RelationGetFile(reln); > > > > > > > -- > Bruce Momjian | http://www.op.net/~candle > maillist@candle.pha.pa.us | (610) 853-3000 > + If your life is a hard drive, | 830 Blythe Avenue > + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 > > >
pgsql-hackers by date: