Обсуждение: Cannot rename init file

Russell,

On Sat, Sep 22, 2001 at 07:29:47PM -0600, Russell Black wrote:
> Last night when I ran vacuumdb, I got the following output:
>
> Vacuuming usda
> NOTICE: Cannot rename init file /cygdrive/c/pgdb/base/167726/
> pg_internal.init.3156 to /cygdrive/c/pgdb/base/167726/pg_internal.init:
> Permission denied
> Continuing anyway, but there's something wrong.
>
> I got similar errors when I tried to perform db operatons using ejb/jdbc. I
> restarted the postmaster and the problem went away. Has anyone else seen
> this?

I have seen the above when running the regression test about 9 months
ago:

    http://archives.postgresql.org/pgsql-ports/2001-01/msg00068.php

But, I have not seen it in a long time -- so I *ass*umed that it was
"fixed" in Cygwin.  If you can reproduce it, then please try to debug it.

BTW, are your running vacuumdb under cron or just at the command line?

> 2nd unrelated (I think) question, I am noticing something funny when I
> run the postmaster with -d2:
>
> postmaster child[2828]: starting with (postgres -d2 -v131072 -p usda )
> FindExec: searching PATH ...
> ValidateBinary: can't stat "/cygdrive/e./postgres"
> ValidateBinary: can't stat "/cygdrive/e./postgres"
> FindExec: found "/usr/bin/postgres" using PATH
> DEBUG: connection: host=127.0.0.1 user=Administrator database=usda
>
> Is the ValidateBinary anything to worry about?

I don't think so.  It just sounds like you have "/cygdrive/e."  in your
PATH before "/usr/bin".

Jason

From: "Jason Tishler" <jason@tishler.net>
> Russell,
>
> On Sat, Sep 22, 2001 at 07:29:47PM -0600, Russell Black wrote:
> > Last night when I ran vacuumdb, I got the following output:
> >
> > Vacuuming usda
> > NOTICE: Cannot rename init file /cygdrive/c/pgdb/base/167726/
> > pg_internal.init.3156 to /cygdrive/c/pgdb/base/167726/pg_internal.init:
> > Permission denied
> > Continuing anyway, but there's something wrong.
> >
> > I got similar errors when I tried to perform db operatons using
ejb/jdbc. I
> > restarted the postmaster and the problem went away.

It seems that to get rid of the error, I only need to close my connections
to the databases with the problem, rather than shutdown the postmaster.

>
> I have seen the above when running the regression test about 9 months
> ago:
>
>     http://archives.postgresql.org/pgsql-ports/2001-01/msg00068.php
>
> But, I have not seen it in a long time -- so I *ass*umed that it was
> "fixed" in Cygwin.  If you can reproduce it, then please try to debug it.

I'm unable to find a set of steps that reproduce it.  It seems to happen
after the jboss server has been running (and has had a connection to the
database) for a couple of days.

>
> BTW, are your running vacuumdb under cron or just at the command line?

I'm running vacuumdb from cron every morning at 3 AM.  How often should I
run vacuumdb?  What exactly does it do?

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.

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.

> How often should I run vacuumdb?  What exactly does it do?

Sorry, I'm not qualified to answer the above.  To be honest, I'm not very
experienced with PostgreSQL.  I just submitted some patches to get 7.0.2
to build under the Cygwin Net Release and the rest is history...  :,)

> 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.

Thanks,
Jason

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...

> -----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