RE: AW: Vacuum only with 20% old tuples

> -----Original Message-----
> From: Zeugswetter Andreas SB [mailto:ZeugswetterA(at)wien(dot)spardat(dot)at]
>
> > > All actions involving a rename of a file imho involve exclusive access
> > > to the table, thus no concurrent access is allowed/possible.
> > >
> >
> > Once a table file was opened,it is not closed until the end of the
> > backend process except due to the shortage of file descriptors.
>
> An open file only references the inode, thus the name can safely
> change underneath, no?

It seems too delicate for me to reply your question correctly.
I don't know the internals of cygwin unfortunately.

Here's a Vadim's *relink* test case in cygwin.

[*relink* to replace a table file by a tmp file]

link(table file, tmp2 file);
fsync(tmp2 file);
unlink(table file);

doesn't fail here even though other processes open the table
file. However any access to the table file seems to be inhibited
while the file is open and

link(tmp file, table file);

fails with the message : Permission denied

fsync(table file);
unlink(tmp file).

However simple *rename* seems to work.

rename(table file,tmp2 file);
rename(tmp file,table file);

seems to cause no error.

> Of course on next real access to a renamed file it would
> need to be closed and opened anew, since it has the wrong file open.
> Looks like it would be good to close files as soon as possible
> once they do not correspond to a valid db object anymore.
>

Sorry I missed this case. Yes this was changed to be handled
correctly before 7.0. Other backends receive relcache invaldation
messages and close the old table files. However other backends
don't receive the message immediately. Backend processes
would never receive the message and keep the table file open
while they are idle. It has been serious for cygwin port.

Regards.

Hiroshi Inoue
Inoue(at)tpf(dot)co(dot)jp