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