From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
Cc: | pgsql-bugs(at)postgresql(dot)org, chjischj(at)163(dot)com |
Subject: | Re: BUG #14687: pg_xlogdump does only count "main data" for record length and leading to incorrect statistics |
Date: | 2017-06-05 08:43:37 |
Message-ID: | 20170605084337.fvm4nfa6c5hu3j2b@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On 2017-06-05 11:23:43 +0300, Heikki Linnakangas wrote:
> On 06/05/2017 05:25 AM, Andres Freund wrote:
> > Hi Heikki,
> > Do you see any better way to get at the !fpi len than to iterate over
> > the blocks and sum up the image length? It's not really accurate to
> > display len (rec/tot) as total-fpi, total, but I don't have a better
> > backward-compatible idea? Actually, I don't even have a better idea for
> > master, so maybe it's ok as proposed?
>
> Your patch seems OK to me. Defining non-FPI size as (total_len - fpi_len)
> seems correct to me, I'm not sure what other definition you could have.
I'm not sure, that's why I chose the above. But you could argue that
the block ids etc. shouldn't be counted as part of either, or that the
previous displaying of record len / total len doesn't make much sense
anymore.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | wangchuanting | 2017-06-05 11:32:17 | Re: BUG #14680: startup process on standby encounter a deadlock of TwoPhaseStateLock when redo 2PC xlog |
Previous Message | Heikki Linnakangas | 2017-06-05 08:39:35 | Re: [PATCH] Sure you meant response? |