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 02:25:11 |
Message-ID: | 20170605022511.imow2t2ojsbauk72@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Hi Heikki,
On 2017-06-04 16:10:12 -0700, Andres Freund wrote:
> On 2017-06-03 16:59:39 +0000, chjischj(at)163(dot)com wrote:
> > Currently, record length in pg_xlogdump/pg_waldump's output only count
> > length of "main data",
>
> Good catch! Will fix.
I notice that this seems to originate in
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=ebc2b681b8ffa597137aa7a19619e6a21176e928
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=2c03216d831160bedd72d45f712601b6f7d03f1c
and that it's not just stats, but also plain xlogdump displaying wrong
data.
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?
- Andres
Attachment | Content-Type | Size |
---|---|---|
waldump.diff | text/x-diff | 3.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | nblxa | 2017-06-05 07:18:22 | BUG #14688: Wrong results in LIKE operation on JSON Type |
Previous Message | Michael Paquier | 2017-06-05 01:28:39 | Re: BUG #14680: startup process on standby encounter a deadlock of TwoPhaseStateLock when redo 2PC xlog |