Claudio Natoli wrote:
>
> Hi all,
>
> was looking at pgunlink, the win32 unlink replacement for postgres, and was
> wondering if it is instead possible (not necessarily make sense to, but
> possible):
> - to simply try the unlink call once, and
> - if unsuccessful with EACCES, mark the file to be deleted some
> later time (ie. next postmaster restart, on system reboot with MoveFileEx,
> ...)
>
> Clearly, this would become burdensome if the file is ever likely to be
> reused again.
>
> So, my question boils down to, effectively, do unlinked files ever get
> rebirthed (eg. if postgres unlinks the file $PGDATA\base\17138, for
> instance, can I ever expect to see this file appear again at a later date?)
> in routine use, or does postgres use ever-increasing file numbers. Perhaps
> after a restore?
Interesting question. In fact, the PeerDirect port, in port/dir.c, you
will see that if the system can't unlink the file in a short time, it
will write the file name into a file that is used later for delayed
deletions.
We do not reuse heap or index files because those are indexed by
relfilenode, and that just increases. However, all those file deletes
happen when we have an exclusive lock on the table. However, I now
remember that the other backends will keep that file opened because it
is part of the their file descriptor cache. SRA's port doesn't have
this problem because they use threading and it is all in one process.
Let's do the port and see how it behaves --- we might need to revisit
this and add such a capability. I have added this to our Win32 TODO
list:
<li>Test if delayed unlink capability is needed</li>
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
