Re: [GENERAL] dropping role w/dependent objects

From: "Ed L(dot)" <pgsql(at)bluepolka(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-patches(at)postgresql(dot)org
Subject: Re: [GENERAL] dropping role w/dependent objects
Date: 2007-05-02 05:04:34
Message-ID: 200705012304.34599.pgsql@bluepolka.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

On Tuesday 01 May 2007 9:34 pm, Tom Lane wrote:
> "Ed L." <pgsql(at)bluepolka(dot)net> writes:
> > [ enlarge MAX_REPORTED_DEPS to 2000 ]
>
> I was about to apply this, but stopped to reflect that it is
> probably not such a hot idea. My concern is that enormously
> long error message detail fields are likely to break client
> software, particularly GUI clients. A poor (e.g., truncated)
> display isn't unlikely, and a crash not entirely out of the
> question. Moreover, who's to say that 2000 is enough lines to
> cover all cases? And if it's not, aren't you faced with an
> even bigger problem?
>
> Perhaps a better solution is to keep MAX_REPORTED_DEPS where
> it is, and arrange that when it's exceeded, the *entire* list
> of dependencies gets reported to the postmaster log; we can
> expect that that will work. We still send the same
> just-the-count message to the client. We could add a hint
> suggesting to look in the postmaster log for the details. This
> would require some refactoring of checkSharedDependencies's
> API, I suppose, but doesn't seem especially difficult.

Fair enough. Something, anything, in the server log would
suffice to identify the problem specifics which are now hidden.
Unfortunately, I won't get to it anytime soon.

Ed

In response to

Browse pgsql-patches by date

  From Date Subject
Next Message Heikki Linnakangas 2007-05-02 10:29:51 Diagnostic functions
Previous Message Tom Lane 2007-05-02 03:34:11 Re: [GENERAL] dropping role w/dependent objects