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:

Previous
From: Oleg Bartunov
Date:
Subject: Re: [HACKERS] strange behavior of UPDATE
Next
From: Ole Gjerde
Date:
Subject: Re: [HACKERS] Sequence nexvtal() and initdb/pg_proc problem