2

Link to the long story happened before (and reason to have) this question.

Does AWS ever vacuumlo PostgreSQL RDS instances?

3

Probably not, because blindly executing vacuumlo on random databases would be foolish.

Unlike vacuum that is pretty much unavoidable on a normal live database, vacuumlo fixes an oversight, a situation that should not arise in the first place, since applications should unlink the large objects that they no longer use, at about the same time that they delete the references to these large objects.

In a database with a large number of large objects that are properly handled, vacuumlo would burn CPU cycles and I/O at each invocation, just to compute every single time that there is nothing to remove.

Moreover, there are two assumptions that vacuumlo must do that are debatable:

  • the fact that any column of type oid should be taken as a candidate to a large object reference. oid are used for other purposes, especially if you want to refer to objects in the catalog.
  • the fact that, if a large object doesn't have it oid refered in some table in the same database , it should be removed. If the reference is in another database, or in a file, or in the same database but embedded in a text column, that logic doesn't work and is in fact dangerous.
  • I partly agree. Only partly because not being used (my ignorance) to either of the assumptions you mention. But the agreed part (the application being broken because not unlinking the objects) together with vacuumlo being contrib make the answer acceptable for me. For the time being. – 48347 Jun 5 '17 at 17:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.