Maybe the nature of the corruption caused is different. It took months of running large databases on production for corruption to become apparent from multixact bugs, for example. Or maybe because the relfrozenxid is fixed by other activity in the system, any bugs are masked -- but that you could get in trouble if autovacuum is disabled, perhaps. Or maybe it's masked even in that case, since autovacuum observes that the table has a very old frozenxid and runs a forced vacuum on that table anyway.
Or maybe there isn’t actual corruption. There is debate in the Git issue discussed over this... I’m not sure. But whatever the case may be, I don’t find it useful to throw out a tool out of hand because of what in theory appears to be a huge bug but which in reality has not happened to a very broad install base of users. pg_repack appears to be the number one way people solve this kind of problem in very critical production environments. So I don’t find it reasonable to just throw out the tool.
> If it (apparently) works so well in practice for so many companies, > but has this bug, why not leverage what they have done [...] ?
What have they done?
Made a tool that can cluster tables, remove bloat and reindex, and move tables between tablespaces with no downtime.
> [...] and fix its bugs when it serves such an important function? The > extension serves a huge need on many fronts.
It's not PGDG's tool, so these are not "our" bugs to fix. Though it's pretty clear that we need *something* to cover those needs ... but nothing has been submitted to commitfests.
I’m not trying to point fingers or say who should do what. My point is that this tool solves some important production challenges and it would be better to leverage this code base and maybe fix some issues then try to write something completely new. And that is largely because there has already been huge production usage of this tool for years which is already exposed many issues that have been fixed.