Re: Cannot rename init file
| От | Russell Black |
|---|---|
| Тема | Re: Cannot rename init file |
| Дата | |
| Msg-id | 00ac01c145e2$700f7070$0464a8c0@iarchives.com обсуждение |
| Ответ на | Re: Cannot rename init file (Jason Tishler <jason@tishler.net>) |
| Список | pgsql-cygwin |
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...
В списке pgsql-cygwin по дате отправления: