Re: reclaiming space from heavily used tables?

>
> 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.
>
> --
> Álvaro Herrera https://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

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.
Many thanks for the feedback,
Jeremy