AW: AW: Vacuum only with 20% old tuples

Поиск
Список
Период
Сортировка
Искать

AW: AW: Vacuum only with 20% old tuples

От:
Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.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? 
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.

> Even now,cygwin port has a flaw that we have no guarantee to
> recreate a table safely after dropping the table. Unfortunately
> we couldn't recreate the same named file until all processes
> close the file in cygwin.

Even if you rename the old file before creating a new one ?
Or is a rename not possible when another process has the file open ?

Andreas

RE: AW: Vacuum only with 20% old tuples

От:
"Hiroshi Inoue" <Inoue@tpf.co.jp>
Дата:
> -----Original Message-----
> From: Zeugswetter Andreas SB [mailto:ZeugswetterA@wien.spardat.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@tpf.co.jp
FAQ