From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Neil Conway <neilc(at)samurai(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: updateable cursors & visibility |
Date: | 2003-03-30 20:32:50 |
Message-ID: | 6191.1049056370@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Hiroshi Inoue writes:
>> Must a SENSITIVE cursor see other applications' changes made
>> while the cursor is open ?
> Yes. It is immaterial whether the change came from a different
> application or the same one.
> Nevertheless, the cursor sensitivity does not excuse you from observing
> the transaction isolation level. So even if the cursor is sensitive you
> should not be able to see other transactions' changes if you are in a
> serializable transaction.
Serializable or not, there is a good case for saying that cursors don't
see changes made after they are opened, period. The current
implementation locks down the cursor's snapshot at DECLARE time. If we
allow the snapshot to change later, what in the world will the semantics
be? Will we go back to re-scan rows that we previously skipped? I do
not think we have a prayer of making consistent, predictable behavior
that works any other way.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | pgsql-bugs | 2003-03-30 23:06:17 | Bug #928: server_min_messages (log_min_messages in CVS) have PGC_USERSET GucContext |
Previous Message | Tom Lane | 2003-03-30 20:29:08 | Re: Detecting corrupted pages earlier |