On Mon, Apr 23, 2018 at 01:02:16PM -0300, Alvaro Herrera wrote:
> Andres Freund wrote:
> > On 2018-04-23 12:37:20 -0300, Alvaro Herrera wrote:
> > > Me too. Should we consider this for pg11? My vote is yes, with no
> > > backpatch (might break scripts reading pg_{wal,xlog}dump output.
> > > Though, really!?).
Breaking the output format is exactly one reason to not patch v10 and
older versions.
> > It's low risk enough, but why should we try to get it into v11? Flags
> > been around for years now.
>
> I was thinking the newly added flags would make for possibly more
> confusing scenarios, but now that I look again, the new ones are XLHL
> flags not the XLOG flags being handled in this patch.
>
> Now, frankly, this being mostly a debugging tool, I think it would be
> better to have the output as complete as we can. Otherwise, when
> debugging some hideous problem we find ourselves patching the tool
> during an emergency in order to figure out what is going on. For this,
> I would rather patch the earliest version we conveniently can. We
> cannot patch pg10 because it's already out there, but not so for pg11.
OK, that works for me. Attached is a patch using hex values for the
flags of all those records (the comment could be fixed further down but
let's not bother about it). There are a couple of things I noticed on
the way:
1) xl_heap_lock prints flags, but not in hexa but using %u.
2) xl_heap_visible prints flags, not in hexa but using %d.
3) xl_heap_lock_updated prints flags, not in hexa but using %u.
4) xl_hash_split_allocate_page has flags, those are handled as directly
text (see hashdesc.c).
5) Most GIN records also have flags, which are handled.
6) xl_smgr_truncate as records, which are not showed up yet.
So I have hacked the patch so as all flags show up in hexa format,
except those which are already handled and print text.
--
Michael