Vacuum/mdtruncate() (was: RE: [HACKERS] Current TODO list) - Mailing list pgsql-hackers
From | Ole Gjerde |
---|---|
Subject | Vacuum/mdtruncate() (was: RE: [HACKERS] Current TODO list) |
Date | |
Msg-id | Pine.LNX.4.05.9905240037190.6022-100000@snowman.icebox.org Whole thread Raw |
In response to | RE: [HACKERS] Current TODO list ("Hiroshi Inoue" <Inoue@tpf.co.jp>) |
List | pgsql-hackers |
On Mon, 24 May 1999, Hiroshi Inoue wrote: > Backends would continue to access the file descritors already hold > if vacuum does nothing about the invalidation of Relation Cache. Yes, and I don't believe that is a problem. I may be wrong however... First, please reverse my patch to mdtruncate() in md.c as soon as possible. It does not work properly in some cases. Second, I do have a better patch in the works. It is included below, but DO NOT APPLY THIS!!! I would like someone to look it over quick. I have checked the logic by hand for a few cases and done a bunch of tests. I would like to test more first. While doing a bunch of vacuums, I have seen some strange things(so my patch probably isn't 100%). I started with 58 segments, and did a bunch of delete/vacuums and got it down to about 5-6. Then I got the error below while running a vacuum analyze. This appeared after the index clean, but before any tuples were moved. ERROR: HEAP_MOVED_IN was not expected Also, I was seeing some more errors about INDEX' TUPLES being higher than HEAP TUPLES. Didn't this just get fixed, or did I break something with my patch. I was seeing these after doing delete/vacuums with my patch. Thanks, Ole Gjerde Index: src/backend/storage/smgr/md.c =================================================================== RCS file: /usr/local/cvsroot/pgsql/src/backend/storage/smgr/md.c,v retrieving revision 1.43 diff -u -r1.43 md.c --- src/backend/storage/smgr/md.c 1999/05/17 06:38:41 1.43 +++ src/backend/storage/smgr/md.c 1999/05/24 06:30:25 @@ -712,32 +712,62 @@#ifndef LET_OS_MANAGE_FILESIZE int curnblk, - i, oldsegno, - newsegno; - char fname[NAMEDATALEN]; - char tname[NAMEDATALEN + 10]; + newsegno, + lastsegblocks, + segcount = 0; + MdfdVec *ov, + *lastv; + MemoryContext oldcxt; + fd = RelationGetFile(reln); curnblk = mdnblocks(reln); - oldsegno = curnblk / RELSEG_SIZE; - newsegno = nblocks / RELSEG_SIZE; - StrNCpy(fname, RelationGetRelationName(reln)->data, NAMEDATALEN); + oldsegno = (curnblk / RELSEG_SIZE) + 1; + newsegno = (nblocks / RELSEG_SIZE) + 1; + oldcxt = MemoryContextSwitchTo(MdCxt); - if (newsegno < oldsegno) { - for (i = (newsegno + 1);; i++) { - sprintf(tname, "%s.%d", fname, i); - if (FileNameUnlink(tname) < 0) - break; + if (newsegno < oldsegno && newsegno > 1) + { + lastv = v = &Md_fdvec[fd]; + for (segcount = 1; v != (MdfdVec *) NULL;segcount++, v = v->mdfd_chain) + { + if(segcount == newsegno) /* Save pointer to last file + in the chain */ + lastv = v; + if(segcount > newsegno) + { + FileUnlink(v->mdfd_vfd); + ov = v; + if (ov != &Md_fdvec[fd]) + pfree(ov); + } } + lastv->mdfd_chain = (MdfdVec *) NULL; } -#endif + /* Find the last file in the md chain */ + for (v = &Md_fdvec[fd]; v->mdfd_chain != (MdfdVec *) NULL;) + v = v->mdfd_chain; + + /* Calculate the # of blocks in the last segment */ + lastsegblocks = nblocks - ((newsegno - 1) * RELSEG_SIZE); + + MemoryContextSwitchTo(oldcxt); + + if (FileTruncate(v->mdfd_vfd, lastsegblocks * BLCKSZ) < 0) + return -1; + +#else + fd = RelationGetFile(reln); + v = &Md_fdvec[fd]; if (FileTruncate(v->mdfd_vfd, nblocks * BLCKSZ) < 0) return -1; + +#endif return nblocks;
pgsql-hackers by date: