Re: Cannot rename init file
От | Dave Page |
---|---|
Тема | Re: Cannot rename init file |
Дата | |
Msg-id | AA30E7BCCA5C1D4E88A231900F8325C00B20@dogbert.vale-housing.co.uk обсуждение исходный текст |
Ответ на | Cannot rename init file ("Russell Black" <rblack@iarchives.com>) |
Список | pgsql-cygwin |
> -----Original Message----- > From: Russell Black [mailto:rblack@iarchives.com] > Sent: 25 September 2001 17:52 > To: Jason Tishler > Cc: pgsql-cygwin@postgresql.org > Subject: Re: [CYGWIN] Cannot rename init file > > > 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... 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
В списке pgsql-cygwin по дате отправления: