pg_background icon indicating copy to clipboard operation
pg_background copied to clipboard

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

Open kirkw opened this issue 2 years ago • 4 comments

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!

kirkw avatar Oct 05 '22 04:10 kirkw

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.

rjuju avatar Oct 05 '22 13:10 rjuju

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

kirkw avatar Oct 05 '22 13:10 kirkw

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 .

rjuju avatar Oct 06 '22 04:10 rjuju

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.

kirkw avatar Oct 06 '22 11:10 kirkw