On Wed, Nov 12, 2014 at 10:59 AM, Andres Freund <and...@2ndquadrant.com> wrote: > On 2014-11-12 11:56:01 -0300, Alvaro Herrera wrote: >> Andres Freund wrote: >> > Hi, >> > >> > On 2014-11-12 09:03:40 -0500, Peter Eisentraut wrote: >> > > Could someone translate this detail message to English: >> > > >> > > ereport(LOG, >> > > (errmsg("logical decoding found consistent point at >> > > %X/%X", >> > > (uint32) (lsn >> 32), (uint32) lsn), >> > > errdetail("running xacts with xcnt == 0"))); >> > >> > It means there a xl_running_xacts record was encountered that had xcnt = >> > 0 - allowing logical decoding to find a consistent start point >> > >> > > (or downgrade to debug message, if appropriate)? >> > >> > The message generally is quite relevant, as the process of finding a >> > consistent start point can take quite a while. we don't really have a >> > nice way to make errdetail() only be logged on a certain severity level >> > as far as I am aware off. >> >> Can we do just the errmsg() and remove with the errdetail? > > No, I really don't want to do that. When trying to see whether logical > replication started that's imo quite an importantdetail. Especially when > first seing > ereport(LOG, > (errmsg("logical decoding found initial starting > point at %X/%X", > (uint32) (lsn >> 32), (uint32) lsn), > errdetail_plural("%u transaction needs to finish.", > "%u transactions > need to finish.", > > builder->running.xcnt, > (uint32) > builder->running.xcnt))); > > Btw, Peter, why did you add a (uint32) to one, but not both, > builder->running.xcnt references? > >> > So maybe 'Encountered xl_running_xacts record with xcnt = 0.'? >> >> That's not very user-facing, is it -- I mean, why bother the user with >> the names of structs and members thereof? It seems better to describe >> what the condition is; something like "found point in time with no >> running transaction". Maybe "point in time" should be "WAL record" >> instead. > > Is that really a win in clarity? When analyzing a problem I'd much > rather have a concrete hint than something fuzzy.
You can't phrase error messages in terms of internal concepts that 99% of users won't understand or care about. Like Peter says, user-facing error messages need to be written in English, not C. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers