Thread: Making dirty reads possible?

Making dirty reads possible?

From
pgsql-sql@vankoperen.nl
Date:
Hi co-fanatics.

I am working on a small prove of concept, and am running into a small 
obstacle. (the prove of concept showing, amongs other things, that doing 
calculations on a database works well, and that it is possible to let it 
run 'jobs')
Considder the following stored procedure:
  For reasons of size the complete code is located on my site:
http://www.vankoperen.nl/concepts/postgresql/primer/index.html

It generates prime numbers for (parameter) odd numbers starting from the 
biggest known prime in the primes table.

The "controller" table makes it possible to abort execution, something 
wich can be handy if you did a 'select primer(10000000);'
I am just getting to grips with the read cashing and the way to 
circumvent it (using the EXECUTE function) so as to read data each time 
and thus react to the newest data, especialy the data in the 
"controller" table in this case.

Now what does not seem to work is the opposite thing: i can not, from 
the console etc, read the new data as the function is generating it.
If i 'SELECT count(*);' at the start, or near the end of the running 
function, it always returns the same. Only when the function is finished 
it commits and the external select returns the new and correct value.
To monitor the function's progress (and for other reasons too, wich are 
not important in this concept yet) i realy want to read either the 
UNCOMMITTED data. Or some way to COMMIT it during the functions 
execution, but currently only the whole function can be regarded as a 
transaction, and nested transactions is not (yet) supported.

Some digging in the mailinglist archives pointed to isolation levels.
Apparently 'dirty reads' in theory:

[quote http://archives.postgresql.org/pgsql-hackers/2004-08/msg01417.php ]
It's only allowed when the transaction is in READ UNCOMMITTED isolation 
level.
Something Postgres doesn't currently support. In fact I'm not aware of 
any SQL
database that supports it, though I'm sure there's one somewhere.

You wouldn't normally want to use such a thing, but it could be useful for,
for example, seeing what progress a transaction has made for a UI progress
meter.
[/quote]

But not possible for real at the moment?


So, summarising:
- Nested transactions is not (yet) supported
- READ UNCOMMITTED isolation level is not (yet) supported
- the EXECUTE plpgsql construct does not circumvent the transaction

Is there a way around this?

Regards,
Ellert.



Re: Making dirty reads possible?

From
Greg Stark
Date:
pgsql-sql@vankoperen.nl writes:

> But not possible for real at the moment?
> 
> So, summarising:
> - Nested transactions is not (yet) supported
> - READ UNCOMMITTED isolation level is not (yet) supported
> - the EXECUTE plpgsql construct does not circumvent the transaction

Well nested transactions are in 8.0 but I don't think they help you much.

I find I've been stymied using server-side functions for large batch jobs for
pretty much the same reason. I find it works better and it's more flexible to
write client-side programs in the language of my choice that connect to the
database and do the batch jobs.

They can output progress logs or keep information about their progress in some
shared space. They can also control the transaction more freely committing in
the middle of the job if it's safe.

-- 
greg



Re: Making dirty reads possible?

From
Josh Berkus
Date:
Guys,

> I find I've been stymied using server-side functions for large batch jobs
> for pretty much the same reason. I find it works better and it's more
> flexible to write client-side programs in the language of my choice that
> connect to the database and do the batch jobs.

FWIW, Gavin Sherry is working on CREATE PROCEDURE for 8.1, which may include 
some ability to have multiple-transaction procedures.

-- 
--Josh

Josh Berkus
Aglio Database Solutions
San Francisco