On Wed, 2006-05-24 at 09:46 -0400, Christopher Browne wrote:
> The world rejoiced as rafal@zorro.isa-geek.com (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
