Skip to content
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

Clear repack index artefacts when dropping the extension #437

Closed
flipsed opened this issue Jan 20, 2025 · 3 comments
Closed

Clear repack index artefacts when dropping the extension #437

flipsed opened this issue Jan 20, 2025 · 3 comments

Comments

@flipsed
Copy link

flipsed commented Jan 20, 2025

We recently started using --only-indexes and started seeing messages like this:

WARNING: Cannot create index "public"."index_613963323", already exists
DETAIL: An invalid index may have been left behind by a previous pg_repack on the table which was interrupted. Please use DROP INDEX "public"."index_613963323" to remove this index and try again.

I can see that the extension drop clears everything else but the indexes. We tend to do

drop extension pg_repack cascade; create extension pg_repack;

if there are leftover repack artefacts but it hasn't been clearing the indexes

za-arthur added a commit that referenced this issue Jan 26, 2025
When using --only-indexes pg_repack uses different approach to repack
indexes, which is running CREATE INDEX CONCURRENTLY command to create a
temporary index and swapping the target index and the temporary index
afterwards.
That approach didn't use any cleanup callbacks and therefore in case of
an error temporary indexes wouldn't be cleaned up.

The commit adds the callback repack_cleanup_index.
@za-arthur
Copy link
Collaborator

@flipsed thank you for the report! I created a PR #440 to fix the issue.

@flipsed
Copy link
Author

flipsed commented Jan 28, 2025

thanks for addressing this @za-arthur 🙌

za-arthur added a commit that referenced this issue Feb 3, 2025
…440)

When using --only-indexes pg_repack uses different approach to repack
indexes, which is running CREATE INDEX CONCURRENTLY command to create a
temporary index and swapping the target index and the temporary index
afterwards.
That approach didn't use any cleanup callbacks and therefore in case of
an error temporary indexes wouldn't be cleaned up.

The commit adds the callback repack_cleanup_index.
@za-arthur
Copy link
Collaborator

I merged the PR #440 and I'm closing this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants