Re: Cannot rename init file

> -----Original Message-----
> From: Russell Black [mailto:rblack(at)iarchives(dot)com]
> Sent: 25 September 2001 17:52
> To: Jason Tishler
> Cc: pgsql-cygwin(at)postgresql(dot)org
> Subject: Re: [CYGWIN] Cannot rename init file
>
>
> From: "Jason Tishler" <jason(at)tishler(dot)net>
> > Russell,
> >
> > On Mon, Sep 24, 2001 at 10:05:52AM -0600, Russell Black wrote:
> > > From: "Jason Tishler" <jason(at)tishler(dot)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...

Don't read too much into that, I put that warning in pgAdmin purely for
common sense reasons rather than a specific issue - you don't want to be
resizing/rearranging potentially huge files while the database is under load
if you can help it, in the same way as you wouldn't defrag a Windows
Terminal server with 20 people logged on (if you could get that many people
logged on without it dying horribly of course :-)).

Regards, Dave