Search Postgresql Archives

Re: reclaiming space from heavily used tables?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]

  Powered by Linux