Adding xmin/xmax to pg_dirtyread output

[bbotev01]

pg_dirtyread is an extremely useful extension with great potential for the purposes of analyzing data issues in large or static tables. It is currently missing one critical component which would help create a timeline for the data changes in the table. Adding system columns (xmin/xmax in particular) to the output would make the extension complete and extremely useful.
Thanks for creating such a great extension,
Boyan Botev

[keithf4]

Just to let you know, I tried looking into this to see if it was easy to add those other columns in. Unfortunately, this takes some internals knowledge I don't currently posses to implement. The code currently uses other internal methods that just return a map of the normally visible columns and I can't see how to do otherwise at this time.

I agree this would make the extension tremendously more useful, so as I learn more I'll definitely keep this in the back of my mind to try and see if I can find the answer. Otherwise, we're always looking for contributions!

[bbotev01]

Thanks for your feedback. As you I spend a good amount of time looking to see if there were any easy options to add xmin/xmax but this requires knowledge and time beyond what I have at the moment. I was able to partially replicate the functionality of pg_dirtyread via another extension called pageinspect. The problem there is that although you can see the xmin,xmax and a lot of other very useful row info, the row data is in bytea format which makes it hard to convert to the appropriate datatype. I have not looked at the pageinspect source but there could be bits and pieces there that may possibly point to a solution on how to add xmin/xmax to pg_dirtyread.

[df7cb]

I've put some effort into making pg_dirtyread a separate repo, fixed a few bugs and added xmin/xmax columns: https://github.com/ChristophBerg/pg_dirtyread
This issue specifically is closed in df7cb/pg_dirtyread@91e5905
Let me know if you are interested in a PR for the original repo - I'll intend to keep the separate repo as well because it'll allow to build Debian packages from it more easily.

[xzilla]

+1 for a PR to this repo :-)

[bbotev01]

This is really great news. Thanks for making this happen Christoph. This is a really powerful feature. I agree a PR for the original repo is probably a good idea for consistency. Thanks again!