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>, "Ole Gjerde" <gjerde(at)icebox(dot)org>
Cc: "PostgreSQL-development" <pgsql-hackers(at)postgreSQL(dot)org>
Subject: RE: [HACKERS] Open 6.5 items
Date: 1999-05-17 09:50:42
Message-ID: 000b01bea04a$ba0582e0$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 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()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.

Thanks.

Hiroshi Inoue
Inoue(at)tpf(dot)co(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
> + If your life is a hard drive, | 830 Blythe Avenue
> + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
>
>
>

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Erik Riedel 1999-05-17 13:14:35 Re: [HACKERS] 64-bit hashjoins
Previous Message Jan Wieck 1999-05-17 09:02:46 Re: [HACKERS] rules regression test