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

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

Reply via email to