WARNING: could not remove database directory

=?ISO-8859-15?Q?Hubert_Fr=F6hlich?= <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:

=?ISO-8859-15?Q?Hubert_Fr=F6hlich?= <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, Pennsylvania 19073

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

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, Pennsylvania 19073

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, Pennsylvania 19073