Message-ID: <16217.125.24.243.247.1158490996.squirrel@webmail.xs4all.nl>
In-Reply-To: <450D21E9.7060807@microbizz.nl>
References: <450A6A87.2030808@microbizz.nl> <450AA301.9020408@microbizz.nl>
	<6009.125.24.242.104.1158397058.squirrel@webmail.xs4all.nl>
	<450D21E9.7060807@microbizz.nl>
Date: Sun, 17 Sep 2006 18:03:16 +0700 (ICT)
Subject: Re: Progress of asynchronous queries
From: "Jeroen T. Vermeulen" <jtv@xs4all.nl>
To: "Adriaan van Os" <postgres@microbizz.nl>
Cc: pgsql-interfaces@postgresql.org
User-Agent: SquirrelMail/1.4.8
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit

On Sun, September 17, 2006 17:22, Adriaan van Os wrote:

>> But you'd be doing this in a transaction anyway: you can't declare a
>> cursor without starting a transaction first.Yes, you could deliberately
>> declare "WITH HOLD" and keep using your cursor after commiting or
>> aborting
>> the transaction.  But even then, so far as I know, the cursor presents a
>> snapshot view of its result set so you get an effective isolation level
>> of
>> "serializable" even then.
>
> No, carefully read
> <http://www.postgresql.org/docs/8.1/static/transaction-iso.html>.

I'm familiar with the document, thank you, but if you're not prepared to
give any detail beyond "no" then I remain unconvinced.  What part exactly
do you disagree with?  That cursors can't be declared without beginning a
transaction first?  That cursors present a snapshot view of their result
set?  That that amounts to an effective isolation level of "serializable?"


>> The number of users has nothing to do with the matter
>
> It does.

No.  Number of concurrent sessions, yes, assuming you're working at "read
committed" isolation level--and even then not for cursors, as I said.


>> if that were a real
>> concern, you'd be using a serializable transaction anyway, so you
>> wouldn't
>> have to worry about it even if cursors did behave as "read committed."
>
> I don't want to be forced to use serializable transaction mode, just
> because I want to know the
> progress of an SQL command.

And that's not what I said.  I said that if you have concerns over the
consistency of your view of the database in the presence of other
concurrent sessions, you'd be using "serializable" transactions in the
first place--*regardless* of whether you want to report progress.


Jeroen