Open yevhene opened 9 years ago
Did you expect the error to be treated in a different way? Or the problem is that this is happening all deletes? If is the later, are you sure the large objects are there before the dele command?
This is happening all deletes. LO is accessible before destroy.
I'll look into it. If you could send some code for a failing spec that would be very helpful :D
Is there any update in this matter? I am facing the same problem.
@ppfp no, sorry. I am moved to simple file storage. (S3 - is alternative).
@ppfp I'm not currently using this code, but if someone provides a failing spec I'd be glad to fix it.
I bypassed the issue by first assigning model instance oid to nil, then saving, then running vacuum_lo then destroying. I do not know how expensive the vacuum_lo operation is, but I think it is fine for my use-case.
Also had this issue, I found that lo_unlink
triggered two times, at first in after_save
callback, and second inafter_commit
callback => so oid is not present at the last call and it fails to delete object.
Has this issue been fixed? When I try to use model.destroy_all, I receive PG::Error: lo_unlink failed. How can I avoid this error in both cases of removing one object and destroying all objects that relate to a particular model instance?
After I delete model from DB,
carrierwave-postgresql
tries to calllo_unlink
but there is no object with thisoid
in db already.I am usin ActiveAdmin. It can be related.