RE: [HACKERS] Open 6.5 items

Поиск
Список
Период
Сортировка
От Hiroshi Inoue
Тема RE: [HACKERS] Open 6.5 items
Дата
Msg-id 000b01bea04a$ba0582e0$2801007e@cadzone.tpf.co.jp
обсуждение исходный текст
Ответы Re: [HACKERS] Open 6.5 items  (Bruce Momjian <maillist@candle.pha.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: jwieck@debis.com (Jan Wieck)
Дата:
Сообщение: Re: [HACKERS] rules regression test
Следующее
От: Erik Riedel
Дата:
Сообщение: Re: [HACKERS] 64-bit hashjoins