I wrote:
> I'm fairly baffled as to why the output order would be unstable
> given the sort, and even more as to why the instability didn't
> emerge before. Any thoughts?
Well, after actually looking at the code, the answer to the first
part of that is obvious: the printed dependency list comes from
checkSharedDependencies(), which is not where I put the sort.
(That is, I fixed DROP OWNED BY, but this error is coming from
DROP ROLE which is not the same code path.)
One might reasonably ask why it's not the same code path, perhaps,
but I'm not really excited about trying to change that right now.
Anyway, looking through our regression tests, there are a total
of four cases where a DROP ROLE command fails with a DETAIL that
mentions more than one object and so might be vulnerable to this
type of problem. (There are several more where we already used
verbosity-reduction to suppress the DETAIL.)
Options:
1. Adjust checkSharedDependencies to sort before constructing the
message. This might have issues if there are lots and lots of
dependencies, but then again we already would have issues due to
the size of the error message.
1a. As above, but add code to limit to limit the number of
dependencies that are stored/sorted/described, even in the
verbose string sent to the server log.
2. De-revert 7d3bf73ac and hope the other cases aren't problems.
3. Change all of those cases to suppress the DETAIL.
1a seems a bit ambitious but maybe it's worth doing, considering
that right now there's a non-negligible chance of OOM if you
try to drop a role that owns a huge number of objects, or just
plain failure due to the stringinfo buffer for the message getting
past MaxAllocSize. Sending a gigabyte-sized message to the server
log could be pretty unfriendly in some contexts, too.
regards, tom lane
