From: "Jason Tishler" <jason@tishler.net>
> Russell,
>
> On Mon, Sep 24, 2001 at 10:05:52AM -0600, Russell Black wrote:
> > From: "Jason Tishler" <jason@tishler.net>
> > > BTW, are your running vacuumdb under cron or just at the command line?
> >
> > I'm running vacuumdb from cron every morning at 3 AM.
>
> Please see if you can reproduce the problem from the command line. I
> have seen some "issues" with cron that I trying to track down myself.
> Since cron is switching user context via NT's security APIs maybe it is
> cause you some permission problems.
>
When it happened the first time, I was able to get the same behavior when I
executed vacuumdb from the command line; I don't think it's a permissions
problem, especially given the fact that the problem goes away when the
client postgres processes die. That makes is sound like it's just a matter
of one process holding open a file so that another process can't delete it.
Unfortunately, I have not found a way to consistently reproduce the problem.
>
> > In the above link, Tom Lane said
> > "The first backend to fire up after a vacuum will try to rebuild
> > pg_internal.init, and then move it into place."
> > Perhaps I should restart my jboss server every time I run vacuumdb, so
the
> > files will be released.
>
> The above sounds like a reasonable workaround -- stop jboss right before
> the nightly vacuumdb. But, it would be much better to understand why
> the rename is failing before resorting to workarounds. If this is truly
> a problem in Cygwin, then we should try to get it fixed. Since I can no
> longer reproduce the problem, I cannot attempt to debug it.
Interestingly, pgAdmin II warns before performing a VACUUM that: "Database
vacuuming should only be performed when there is no one using the database."
Maybe my "work-around" is really the way it's supposed to be done...