| From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
|---|---|
| To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: cursor sensitivity misunderstanding |
| Date: | 2021-02-18 18:14:30 |
| Message-ID: | af957f28-1c41-2470-3294-a19dd6e852f8@enterprisedb.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 18.02.21 17:11, David G. Johnston wrote:
> The OP was doing a course based on Oracle and was confused regarding our
> behavior. The documentation failed to help me provide a useful
> response, so I'd agree there is something here that needs reworking if
> not outright fixing.
According to the piece of the standard that I posted, the sensitivity
behavior here is implementation-dependent (not even -defined), so both
implementations are correct.
But the poster was apparently also confused by the same piece of
documentation.
If you consider the implementation of MVCC in PostgreSQL, then the
current behavior makes sense. I suspect that this consideration was
much more interesting for older system with locking-based concurrency
and where "read uncommitted" was a real thing. With the current system,
insensitive cursors are essentially free and sensitive cursors would
require quite a bit of effort to implement.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2021-02-18 18:53:05 | Re: Some regular-expression performance hacking |
| Previous Message | Tom Lane | 2021-02-18 18:10:47 | Re: Some regular-expression performance hacking |