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

If I just call pg_background_launch() is that good enough for an Asynchronous call? #40

Open
kirkw opened this issue Oct 5, 2022 · 4 comments

Comments

@kirkw
Copy link

kirkw commented Oct 5, 2022

The ESSENCE of this question is...
does it do any harm to ignore the results? Just run the code and let it finish...
Will it close things up properly when done?

I've monitored this on Linux (ps -ax) and the session appears to go away when finished.
I just want to make sure I am not creating any kind of memory leak!

@rjuju
Copy link
Collaborator

rjuju commented Oct 5, 2022

Unfortunately no. The only reason you see the background worker exiting is because it didn't send more traffic than the queue size (by default 65k, see https://github.com/vibhorkum/pg_background/blob/master/pg_background--1.0.sql#L6). If the underlying query generates more traffic it will just get blocked until some process tries to read from the message queue (which is what pg_background_result() does) and free some memory in the message queue.

But even if it appears to be ok, the message queue will still be allocated and will persist in memory until you call pg_background_result.

@kirkw
Copy link
Author

kirkw commented Oct 5, 2022

Excellent answer. So avoid the asynchronous attempt, and always call pg_background_result()!
Thank you!

@rjuju
Copy link
Collaborator

rjuju commented Oct 6, 2022

Note that there's also the pg_background_detach(pid) function. It's not entirely clear to me what it exactly mean for the query text launched, but I think that it will just mean that everything will be run to completion as it would normally have, except that the worker will stop sending the output protocol data to the message queue.

The only problem with this approach is that you also won't be able to know if you hit an error or not processing the query. So unless you're happy with the query maybe failing without knowing, it makes it only usable as a last resort cleanup .

@kirkw
Copy link
Author

kirkw commented Oct 6, 2022

Thank you. Unfortunately I need the Exception to bubble back up.
I just call this with so many different calls (Inserts, CALL Procedure(), etc.), and getting the results wrong breaks it (since I wrapped it, so I can test/compare our code base using this versus FDW/DBLink, by changing only one procedure).

My Linux guru sent me the notes on how to test this (forgive me, windows developer forever, new to git, etc.).
I will test today. I needed to make a snapshot of my VM in case it goes badly. LOL.

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

No branches or pull requests

2 participants