Thread: Re: [GENERAL] WARNING: could not remove database directory
Hubert Fröhlich <hubert.froehlich@bvv.bayern.de> writes:
> dropdb ax20050206
> WARNING: could not remove database directory
> "/export/home/postgres/data2/base/115101837"
> DROP DATABASE
That's not very helpful, is it?
[ looks at code... ] dbcommands.c is expecting that rmtree() will have
printed out a more-detailed message about the problem, but someone has
carefully removed every trace of error reporting from rmtree().
regards, tom lane
Tom Lane wrote: > Hubert Fröhlich <hubert.froehlich@bvv.bayern.de> writes: > > dropdb ax20050206 > > WARNING: could not remove database directory > > "/export/home/postgres/data2/base/115101837" > > DROP DATABASE > > That's not very helpful, is it? > > [ looks at code... ] dbcommands.c is expecting that rmtree() will have > printed out a more-detailed message about the problem, but someone has > carefully removed every trace of error reporting from rmtree(). I think the issue is that we didn't want different object files for client and server output message and and returning error codes and having every calling location print strings was unmaintainable. Seems we never got a solution to that. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> [ looks at code... ] dbcommands.c is expecting that rmtree() will have
>> printed out a more-detailed message about the problem, but someone has
>> carefully removed every trace of error reporting from rmtree().
> I think the issue is that we didn't want different object files for
> client and server output message and and returning error codes and
> having every calling location print strings was unmaintainable.
But we already bit that bullet. Look at the other routines in dirmod.c:
#ifndef FRONTEND ereport(ERROR, (errcode_for_file_access(), errmsg("Error setting
junctionfor %s: %s", nativeTarget, msg)));
#else fprintf(stderr, "Error setting junction for %s: %s\n", nativeTarget, msg);
#endif
It's certainly not realistic to pass back enough information from
rmtree() to let the caller print a useful error message, so I think
we have to add reporting code along this line to rmtree().
regards, tom lane
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Tom Lane wrote:
> >> [ looks at code... ] dbcommands.c is expecting that rmtree() will have
> >> printed out a more-detailed message about the problem, but someone has
> >> carefully removed every trace of error reporting from rmtree().
>
> > I think the issue is that we didn't want different object files for
> > client and server output message and and returning error codes and
> > having every calling location print strings was unmaintainable.
>
> But we already bit that bullet. Look at the other routines in dirmod.c:
>
> #ifndef FRONTEND
> ereport(ERROR,
> (errcode_for_file_access(),
> errmsg("Error setting junction for %s: %s",
> nativeTarget, msg)));
> #else
> fprintf(stderr, "Error setting junction for %s: %s\n",
> nativeTarget, msg);
> #endif
>
> It's certainly not realistic to pass back enough information from
> rmtree() to let the caller print a useful error message, so I think
> we have to add reporting code along this line to rmtree().
Agreed. Not sure how the rmtree stuff was removed. I will look into
re-adding it, I assume for 8.1 only not 8.0.X?
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> It's certainly not realistic to pass back enough information from
>> rmtree() to let the caller print a useful error message, so I think
>> we have to add reporting code along this line to rmtree().
> Agreed. Not sure how the rmtree stuff was removed. I will look into
> re-adding it, I assume for 8.1 only not 8.0.X?
I'd put it into 8.0 as well. The only reason not to is that the strings
won't be translated (unless the translators add them later) ... but an
untranslated message is still tons better than no message at all.
Speaking of untranslated, the fprintf(stderr) calls in the other
routines are missing the gettext() invocations they need to have to be
translatable, so they have problems already.
regards, tom lane
8.0.X will have proper filename reporting for rmtree() failures.
---------------------------------------------------------------------------
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Tom Lane wrote:
> >> [ looks at code... ] dbcommands.c is expecting that rmtree() will have
> >> printed out a more-detailed message about the problem, but someone has
> >> carefully removed every trace of error reporting from rmtree().
>
> > I think the issue is that we didn't want different object files for
> > client and server output message and and returning error codes and
> > having every calling location print strings was unmaintainable.
>
> But we already bit that bullet. Look at the other routines in dirmod.c:
>
> #ifndef FRONTEND
> ereport(ERROR,
> (errcode_for_file_access(),
> errmsg("Error setting junction for %s: %s",
> nativeTarget, msg)));
> #else
> fprintf(stderr, "Error setting junction for %s: %s\n",
> nativeTarget, msg);
> #endif
>
> It's certainly not realistic to pass back enough information from
> rmtree() to let the caller print a useful error message, so I think
> we have to add reporting code along this line to rmtree().
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073