RE: [HACKERS] Open 6.5 items

Поиск
Список
Период
Сортировка
От Hiroshi Inoue
Тема RE: [HACKERS] Open 6.5 items
Дата
Msg-id 000c01beacd4$aba95c80$2801007e@cadzone.tpf.co.jp
обсуждение исходный текст
Ответ на Re: [HACKERS] Open 6.5 items  (Bruce Momjian <maillist@candle.pha.pa.us>)
Ответы RE: [HACKERS] Open 6.5 items
Список pgsql-hackers
> -----Original Message-----
> From: owner-pgsql-hackers@postgreSQL.org
> [mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Bruce Momjian
> Sent: Monday, May 31, 1999 3:15 PM
> To: Hiroshi Inoue
> Cc: PostgreSQL-development
> Subject: Re: [HACKERS] Open 6.5 items
> 
> 
> > I couldn't explain more because of my poor English,sorry.
> > 
> > But my test case usually causes backend abort.
> > My test case is
> >     While 1 or more sessions frequently insert/update a table,
> >     vacuum the table.
> > 
> > After vacuum, those sessions abort with message 
> >     ERROR:  cannot open segment .. of relation ...
> > 
> > This ERROR finally causes spinlock freeze as I reported in a posting
> > [HACKERS] spinlock freeze ?(Re: INSERT/UPDATE waiting (another 
> > example)). 
> > 
> > Comments ?
> 
> OK, I buy that.  How will truncate fix things?  Isn't that going to be
> strange too.  Hard to imagine how we are going to modify these things. 
> I am now leaning to the truncate option, especially considering that
> usually only the last segment is going to be truncated.
>

I made a patch on trial.

1)  Useless segments are never removed by my implementation     because I call FileTruncate() instead of
File(Name)Unlink().
2)  mdfd_lstbcnt member of MdfdVec was abused in mdnblocks().    I am maintaining the value of mdfd_lstbcnt
unwillingly.   Is it preferable to get rid of mdfd_lstbcnt completely ?
 

I'm not sure that this patch has no problem.
Please check and comment on my patch.

I don't have > 1G disk space.
Could someone run under > 1G environment ?
As Ole Gjerde mentioned,current implementation by his old 
patch is not right.  His new patch seems right if vacuum is 
executed alone.
Please run vacuum while other concurrent sessions are 
reading or writing,if you would see the difference.

Thanks.

Hiroshi Inoue
Inoue@tpf.co.jp

*** storage/smgr/md.c.orig    Wed May 26 16:05:02 1999
--- storage/smgr/md.c    Wed Jun  2 15:35:35 1999
***************
*** 674,684 ****     segno = 0;     for (;;)     {
!         if (v->mdfd_lstbcnt == RELSEG_SIZE
!             || (nblocks = _mdnblocks(v->mdfd_vfd, BLCKSZ)) == RELSEG_SIZE)         {
- 
-             v->mdfd_lstbcnt = RELSEG_SIZE;             segno++;              if (v->mdfd_chain == (MdfdVec *) NULL)
--- 674,685 ----     segno = 0;     for (;;)     {
!         nblocks = _mdnblocks(v->mdfd_vfd, BLCKSZ);
!         if (nblocks > RELSEG_SIZE)
!             elog(FATAL, "segment too big in mdnblocks!");
!         v->mdfd_lstbcnt = nblocks;
!         if (nblocks == RELSEG_SIZE)         {             segno++;              if (v->mdfd_chain == (MdfdVec *)
NULL)
***************
*** 714,745 ****     int            curnblk,                 i,                 oldsegno,
!                 newsegno;
!     char        fname[NAMEDATALEN];
!     char        tname[NAMEDATALEN + 10];      curnblk = mdnblocks(reln);     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);     v = &Md_fdvec[fd];      if (FileTruncate(v->mdfd_vfd, nblocks *
BLCKSZ)< 0)         return -1;      return nblocks; 
 
--- 715,766 ----     int            curnblk,                 i,                 oldsegno,
!                 newsegno,
!                 lastsegblocks;
!     MdfdVec            **varray;      curnblk = mdnblocks(reln);
+     if (nblocks > curnblk)
+         return -1;     oldsegno = curnblk / RELSEG_SIZE;     newsegno = nblocks / RELSEG_SIZE;  #endif      fd =
RelationGetFile(reln);    v = &Md_fdvec[fd]; 
 
+ #ifndef LET_OS_MANAGE_FILESIZE
+     varray = (MdfdVec **)palloc((oldsegno + 1) * sizeof(MdfdVec *));
+     for (i = 0; i <= oldsegno; i++)
+     {
+         if (!v)
+             elog(ERROR,"segment isn't open in mdtruncate!");
+         varray[i] = v;
+         v = v->mdfd_chain;
+     }
+     for (i = oldsegno; i > newsegno; i--)
+     {
+         v = varray[i];
+         if (FileTruncate(v->mdfd_vfd, 0) < 0)
+         {
+             pfree(varray);
+             return -1;
+         }
+         v->mdfd_lstbcnt = 0;
+     }
+     /* Calculate the # of blocks in the last segment */
+     lastsegblocks = nblocks - (newsegno * RELSEG_SIZE);
+     v = varray[newsegno];
+     pfree(varray);
+     if (FileTruncate(v->mdfd_vfd, lastsegblocks * BLCKSZ) < 0)
+         return -1;
+     v->mdfd_lstbcnt = lastsegblocks;
+ #else     if (FileTruncate(v->mdfd_vfd, nblocks * BLCKSZ) < 0)         return -1;
+     v->mdfd_lstbcnt = nblocks;
+ #endif      return nblocks; 




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Zalman Stern
Дата:
Сообщение: Re: [HACKERS] Re: [SQL] Column name's length
Следующее
От: wieck@debis.com (Jan Wieck)
Дата:
Сообщение: Re: [HACKERS] Re: [SQL] Column name's length