Robert Haas escribió:
> There's that, too. But again, these messages are not can't-happen
> scenarios. The argument is just whether to reuse existing error
> message text (like "could not write file") or invent a new variation
> (like "could not write remapping file"). Andres' argument (which is
> valid) is that distinguished messages make it easier to troubleshoot
> without needing to turn on verbose error messages. My argument (which
> I think is also valid) is that a user isn't likely to know what a
> remapping file is, and having more messages increases the translation
> burden. Is there a project policy on this topic?
I would vote for a generic "could not write file %s" where the %s lets
the troubleshooter know the path of the file, and thus in what context
it is being read. We already have a similar case where slru.c reports
error as pertaining to "transaction 12345" but the path is
"pg_subtrans/xyz" or multixact etc; while it doesn't explicitely say
what module is raising the error, it's pretty clear from the path.
Would that not work here?
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
