From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Neil Conway <neilc(at)samurai(dot)com>, Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: updateable cursors & visibility |
Date: | 2003-03-27 15:23:45 |
Message-ID: | Pine.LNX.4.44.0303271011280.2228-100000@peter.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian writes:
> One idea is to require FOR UPDATE on the cursor --- while that prevents
> other transactions from changing the cursor, it doesn't deal with the
> current transaction modifying the table outside the cursor.
That would only keep existing rows from being deleted but not new rows
from being added.
> One idea is
> to have UPDATE/DELETE WHERE CURRENT OF behave like UPDATE/DELETE do now
> when they find a row that is locked by another transaction --- they wait
> to see if the transaction commits or aborts, then if committed they
> follow the tid to the newly updated row, check the WHERE clause to see
> if it still is satisfied, then perform the update. (Is this correct?)
Surely it would have to do something like that, but that's a matter of the
transaction isolation, not the sensitivity. It doesn't do anything to
address the potential problems I mentioned.
--
Peter Eisentraut peter_e(at)gmx(dot)net
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2003-03-27 15:24:04 | Re: Autoheader plan |
Previous Message | Teodor Sigaev | 2003-03-27 15:23:40 | Re: BUG: Vacuum Analyze - datumGetSize: Invalid typLen |