Re: [GENERAL] WARNING: could not remove database directory

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Hubert Fröhlich <hubert(dot)froehlich(at)bvv(dot)bayern(dot)de>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [GENERAL] WARNING: could not remove database directory
Date: 2005-02-14 16:25:10
Message-ID: 200502141625.j1EGPAL26146@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers


8.0.X will have proper filename reporting for rmtree() failures.

---------------------------------------------------------------------------

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2005-02-14 16:45:06 Re: SQL Injection possible on custom functions
Previous Message Tom Lane 2005-02-14 16:19:15 Re: pg_dump warnings

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2005-02-14 16:27:47 Re: Help me recovering data
Previous Message Tom Lane 2005-02-14 16:11:53 Re: Schema name of function