Обсуждение: RE: [HACKERS] Open 6.5 items

Поиск
Список
Период
Сортировка

RE: [HACKERS] Open 6.5 items

От
"Hiroshi Inoue"
Дата:

> -----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
> 
> 
> 


Re: [HACKERS] Open 6.5 items

От
Bruce Momjian
Дата:
> > 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()ed segment 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 more secure to truncate segment files to 0 length 
>    than unlinking those files. But I'm not sure it works fine.

Unlink still allows open file descriptors to continue being valid.  The
file is removed only when the kernel open file descriptor reference
count is zero.

--  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,
Pennsylvania19026