tags:

views:

236

answers:

3

I have a long running function that should be inserting new rows. How do I check the progress of this function?

I was thinking dirty reads would work so I read http://www.postgresql.org/docs/8.4/interactive/sql-set-transaction.html and came up with the following code and ran it in a new session:


SET SESSION CHARACTERISTICS AS SERIALIZABLE;

SELECT * FROM MyTable;

Postgres gives me a syntax error. What am I doing wrong? If I do it right, will I see the inserted records while that long function is still running?

Thanks

A: 

try this:

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
nathan
It liked that. However, it still wouldn't let me see the inserts already performed by the function. Do you know if it's just missing for a while.
User1
I've used this approach with MySQL, but I've never actually tried it in PostgreSQL. Are you sure you are running in a transaction? Here is a not from the docs: "If SET TRANSACTION is executed without a prior START TRANSACTION or BEGIN, it will appear to have no effect, since the transaction will immediately end.It is possible to dispense with SET TRANSACTION by instead specifying the desired transaction_modes in BEGIN or START TRANSACTION. "
nathan
PostgreSQL does not implement READ UNCOMMITTED
Magnus Hagander
+3  A: 

PostgreSQL does not implement a way for you to see this from outside the function, aka READ UNCOMMITTED isolation level. Your basic two options are:

  • Have the function use RAISE NOTICE every now and then to show you how far along you are
  • Use something like dblink from the function back to the same database, and update a counter table from there. Since that's a completely separate transaction, the counter will be visible as soon as that transaction commits - you don't have to wait for the main transaction (around the function call) to finish.
Magnus Hagander
+1  A: 

PostgreSQL Transaction Isolation

In PostgreSQL, you can request any of the four standard transaction isolation levels. But internally, there are only two distinct isolation levels, which correspond to the levels Read Committed and Serializable. When you select the level Read Uncommitted you really get Read Committed, and when you select Repeatable Read you really get Serializable, so the actual isolation level might be stricter than what you select. This is permitted by the SQL standard: the four isolation levels only define which phenomena must not happen, they do not define which phenomena must happen.

Triqui