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