On Wed, 2006-05-24 at 09:46 -0400, Christopher Browne wrote: > The world rejoiced as rafal@xxxxxxxxxxxxxxxxxx (Rafal Pietrak) wrote: > > My impression was, that I get the next prompt after the procedure > > finishes, so it wouldn't be a solution. But if (2) applies, that is > > really it.... Frankly, it would take me some time to get back to those > > sources (and generate simulation data) - so anybody knows the answer? > > It depends on something else... > > Is the process that is starting up the "background batch process" > making other changes to the data? OK. just to focus attention: 1. I have a batch of INSERTS done by program called "main" - a simple cgi-bin/script in perl. 2. I have a stored procedure installed within the RDBMS. 3. that procedure is executed as the last 'intentional' DB request done by my main script. 4. then the script would like to exit, leaving 'stored procedure' doing whatever that procedure is designed to do, but it'll take more then a couple of minutes to complete. 5. would my main process have to wait (given current implementation of libpq) for that procedure to finish? Or the PG_disconnect finishes right away, without waiting for procedure return? 6. the procedure, after minutes of busy housekeeping the database, does a final COMMIT. But the main process that called it is long gone by that time. In my script I do: "Batch-INSERTS; COMMINT; call procedure; exit"; I'm not quite sure if I can write a stored procedure so, that in case when: INSERT takes 5min, call_proc takes 20min, --> the whole script returns after 5min (meaning, time needed by the stored procedure to execute does not influence script execution time)? If I can write such procedure ... triggers are stored procedures, I could try to write such trigger??? -R
