Skip to content

fix(#193): only create indexes if table does not exist#194

Merged
witash merged 3 commits intomainfrom
193-dont-create-indexes
Dec 11, 2024
Merged

fix(#193): only create indexes if table does not exist#194
witash merged 3 commits intomainfrom
193-dont-create-indexes

Conversation

@witash
Copy link
Contributor

@witash witash commented Dec 9, 2024

closes #193

check if table exists in a separate query before creating indexes

@witash witash requested a review from dianabarsan December 9, 2024 12:57
Copy link
Member

@dianabarsan dianabarsan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sweet. One minor change + unit test request.

// note that `CREATE INDEX IF NOT EXISTS` acquires a lock
// even if the index exists, so cannot rely on it here,
// have to actually check if the table exists in a separate query
const tableExists = await checkTableExists(client);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can return early here instead:

Suggested change
const tableExists = await checkTableExists(client);
if (await checkTableExists(client)) {
return;
}

end: sinon.stub(),
};

pgClient.query.withArgs(`SELECT 1 FROM v1.whatever LIMIT 1;`).rejects({
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add a unit test where the table already exists and doesn't get created on startup.

return true;
} catch (error) {
// "Undefined table" error code in PostgreSQL
if (error.code === '42P01') {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we should have a library of PG errors somewhere instead of scattered magic strings all over. Do we have other PG errors that we work around in this codebase?

@witash
Copy link
Contributor Author

witash commented Dec 10, 2024

looking a bit deeper into postgres locking and there's a simpler way to fix this; using CREATE INDEX CONCURRENTLY IF NOT EXISTS acquires a less restrictive lock ('SHARE UPDATE EXCLUSIVE') which doesn't conflict with the type of lock that inserts get ('ROW EXCLUSIVE').

@witash witash requested a review from dianabarsan December 10, 2024 11:57
Copy link
Member

@dianabarsan dianabarsan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for spending extra time to read about how locks get triggered in PG! This is absolutely much better!

@witash witash merged commit 0e6b671 into main Dec 11, 2024
@witash witash deleted the 193-dont-create-indexes branch December 11, 2024 08:47
@medic-ci
Copy link

🎉 This PR is included in version 1.3.1 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

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

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Creating indexes on startup of couch2pg causes locks in postgres

3 participants