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.

Unlink still allows open file descriptors to continue being valid. The
file is removed only when the kernel open file descriptor reference
count is zero.

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