Re: what does this mean: "running xacts with xcnt == 0"

On Wed, Nov 12, 2014 at 10:59 AM, Andres Freund <andres(at)2ndquadrant(dot)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