On Sat, Oct 14, 2017 at 10:58 AM, Robert Haas <robertmh...@gmail.com> wrote: > I think it's perfectly sensible to view those 2 bits as making up a > 2-bit field with 4 states rather than displaying each bit > individually, but you obviously disagree. Fair enough.
I guess it is that simple. > I can think of two possible explanations for that. Number one, the > tool was written before HEAP_XMIN_FROZEN was invented and hasn't been > updated for those changes. Have we invented our last t_infomask/t_infomask2 (logical) status already? > Number two, the author of the tool agrees > with your position rather than mine. I am working on an experimental version of pg_filedump, customized to output XML that can be interpreted by an open source hex editor. The XML makes the hex editor produce color coded, commented tags/annotations for any given heap or B-Tree relation. This includes tooltips with literal values for all status bits (including t_infomask/t_infomask2 bits, IndexTuple bits, B-Tree meta page status bits, PD_* page-level bits, ItemId bits, and others). I tweeted about this several months ago, when it was just a tool I wrote for myself, and received a surprisingly positive response. It seems like I'm on to something, and should release the tool to the community. I mention this project because it very much informs my perspective here. Having spent quite a while deliberately corrupting test data in novel ways, just to see what happens, the "work backwards from the storage format" perspective feels very natural to me. I do think that I understand where you're coming from too, though. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
