Tom Lane wrote: > "Ed L." <[EMAIL PROTECTED]> 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.
Actually I was thinking that we could report MAX_REPORTED_DEPS (the original value) dependencies to the client log, and finish with "and other N dependencies not shown here". Maybe we could mix both solutions and send a partial report to the client and a full report to the server log. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
