-
Notifications
You must be signed in to change notification settings - Fork 176
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Repack without trigger #412
Comments
Not really, I think. What you can do is start a transaction, get a write lock on the table, and then INSERT-SELECT into a new table. Then rename it. All in one transaction. |
You can try to redefine functions
or pg_repack/lib/pg_repack.sql.in Lines 300 to 301 in 6a3c282
It works when I do a simple test. But we don't generally test such case. |
I was able to comment out the |
AFAIK a PK/unique index is used by DELETE/UPDATE operations during applying log: pg_repack/lib/pg_repack.sql.in Lines 312 to 313 in 6a3c282
You can try to redefine pg_repack/lib/pg_repack.sql.in Lines 317 to 318 in 6a3c282
|
We have a unique scenario where we are looking to repack an active table that gets frequent reads, but all of its writes are controlled and infrequent. The table, due to its creation from another extension, does not support triggers but in this case we do not actually need to worry about keeping track of replay logs. Our main goal is to benefit from pg_repack's ability to copy live (with handling of locks) and then ultimately
swap
carefully to ensure that nothing is broken out from under it.Is there any simple way to run pg_repack, ignoring the steps to create/activate the replay log trigger?
Thanks!
The text was updated successfully, but these errors were encountered: