RE: [HACKERS] Open 6.5 items

From: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>
To: "Bruce Momjian" <maillist(at)candle(dot)pha(dot)pa(dot)us>
Cc: "PostgreSQL-development" <pgsql-hackers(at)postgreSQL(dot)org>
Subject: RE: [HACKERS] Open 6.5 items
Date: 1999-06-02 08:48:22
Message-ID: 000c01beacd4$aba95c80$2801007e@cadzone.tpf.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> -----Original Message-----
> From: owner-pgsql-hackers(at)postgreSQL(dot)org
> [mailto:owner-pgsql-hackers(at)postgreSQL(dot)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(at)tpf(dot)co(dot)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;

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jan Wieck 1999-06-02 08:51:50 Re: [HACKERS] Re: [SQL] Column name's length
Previous Message Zalman Stern 1999-06-02 06:17:54 Re: [HACKERS] Re: [SQL] Column name's length