Skip to content

Conversation

Y--
Copy link
Collaborator

@Y-- Y-- commented Jan 16, 2025

Up until now, we were starting the background worker as part of the extension.

The problem with this approach is that it imposes a unique worker, and thus cannot updated multiple database.

In preparation to have one BGW per database, this PR triggers the start of a background worker when IsExtensionRegistered is called and the cache is populated.

We've prevented potential race conditions that would cause two bgw to start by checking a lock on a temporary file.

Note: a following PR will actually start one BGW per database

@Y-- Y-- requested a review from JelteF January 16, 2025 16:54
@Y-- Y-- force-pushed the yl/md-bgw-per-db branch 3 times, most recently from 4c84f96 to 865c10b Compare January 17, 2025 10:08
@JelteF JelteF added this to the 0.4.0 milestone Jan 28, 2025
@JelteF JelteF added the MotherDuck Issues related to MotherDuck label Jan 28, 2025
@Y-- Y-- force-pushed the yl/md-bgw-per-db branch 3 times, most recently from d41ee16 to 8338b48 Compare March 5, 2025 14:12
@@ -252,13 +341,13 @@ InitBackgroundWorker(void) {
#else
ShmemRequest();
#endif
Copy link
Collaborator

Choose a reason for hiding this comment

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

I think this should also be in InitBackgroundWorkersShmem. And I think that's probably the reason why you now needed the BgwShmemStruct->lock in TriggerActivity. So if you move this code I think you can remove the changes to TriggerActivity

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I'm actually still getting the segfault when moving that around. Though I agree, it makes more sense to put it there.

void
InitBackgroundWorker(void) {
InitBackgroundWorkersShmem(void) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
InitBackgroundWorkersShmem(void) {
InitBackgroundWorkerShmem(void) {

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

The s was intentional - it does initialize memory of all BG workers that may be spawned (when there are one per DB). Technically it's not in this PR, so maybe I can rename later?

@Y-- Y-- requested a review from JelteF March 7, 2025 12:44
@Y-- Y-- force-pushed the yl/md-bgw-per-db branch from d51b095 to 9afb7ec Compare March 10, 2025 13:00
@Y-- Y-- enabled auto-merge (squash) March 10, 2025 13:01
@Y-- Y-- requested a review from JelteF March 10, 2025 13:02
@Y-- Y-- merged commit 1454c14 into main Mar 10, 2025
5 checks passed
@Y-- Y-- deleted the yl/md-bgw-per-db branch March 10, 2025 13:08
Y-- added a commit that referenced this pull request Apr 22, 2025
Following #544, remove the
`duckdb.motherduck_postgres_database` GUC parameter and start a
background worker for each PG database (*)

For another database to synchronize with the BGW to work:
* extension must be created: `CREATE EXTENSION pg_duckdb;`
* `duckdb` should be able to write in `public` schema: `GRANT ALL ON
SCHEMA public to duckdb;`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
MotherDuck Issues related to MotherDuck
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants