> I will try separate my huge data computation into several pieces > something like: [...] > If I understood correctly, "begin ... exception when .. then ... end" > can work the same way as commit. In another way, if commands in the > sub-block (such as step1) run successfully, data in this part (step1) is > committed. Then step2, step3... stepN that are all under "begin.. > exception.. end" sub-blocks will be run and "committed" one by one. begin...exception...end; does not break up the transaction into smaller subtransactions. it does however allow graceful handling from errors inside a function but that is not what you are looking for. To put it another way, it is impossible for any part of the work inside the function to become visible to other backends unless you leave the function without error and the transaction that wraps it (if there is one) is comitted. > "To define a procedure, i.e. a function that returns nothing, just > specify RETURNS VOID. " > Copied from > http://www.postgresql.org/docs/8.1/interactive/sql-createfunction.html > > So, a stored procedure is "a void function", right? yes and no. Yes in that a procedure differs from a function in that it returns no value. No in that 'pure' stored procedures discussed some months back in hackers (and IIRC not implemented yet) are not transactional entities. They are like server side sql scripts that take parameters. Try running vacuum inside a function...it doen't work but it would inside a non function based stored procedure. I think your best bet is to first try Florian's approach of the monolithic query and see if it works for you...if it does, great. If not, you have basically three options: 1. in transaction cursor: declare your input cursor in transaction and fetch x rows at a time (say, 1000) and write them back over another transaction comitting as you go. This is insensitive in that you can't see changes as you loop through the set. 2.non transactional cursor: using only one connection you declare your cursor 'with hold' and loop over and insert over same connection. Just beware that postgresql must materialize 'with hold' cursors into a temporary table. This approach is also insensitive. 3. client side table browsing. You can browse your tables ISAM style. This is a fancy way of saying you use client code to loop over a table ordered on a key. This approach can be sensitive (one connection) or insensitive (two connections) while preserving the ablity to commit as you go. merlin
