Re: what does this mean: "running xacts with xcnt == 0" - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: what does this mean: "running xacts with xcnt == 0"
Date
Msg-id 546555E3.2060908@gmx.net
Whole thread Raw
In response to Re: what does this mean: "running xacts with xcnt == 0"  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
On 11/12/14 10:59 AM, Andres Freund wrote:
> 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?

The cast on the second reference was already there, presumably to match
the %u format.  (The compiler might complain otherwise.)  The first
argument doesn't need a cast, because it's a declared (not variadic)
argument, and so the compiler will cast it automatically.

>> 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.

If the output is primarily useful to you only, then it should be a
debug-level message.




pgsql-hackers by date:

Previous
From: Andreas Karlsson
Date:
Subject: Re: Using 128-bit integers for sum, avg and statistics aggregates
Next
From: David Johnston
Date:
Subject: Re: Re: [GENERAL] Performance issue with libpq prepared queries on 9.3 and 9.4