From: | Mark Slagell <ms(at)iastate(dot)edu> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Dave Page <dpage(at)vale-housing(dot)co(dot)uk>, pgsql-odbc(at)postgresql(dot)org |
Subject: | Re: psqlodbc versioning |
Date: | 2004-07-08 20:59:19 |
Message-ID: | 40EDB5A7.60209@iastate.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-odbc |
Peter Eisentraut wrote:
>
> Could you show us some kind of specification about what this new lock
> reporting interface would look like (what functions, what parameters,
> etc.)?
I'll try to get some input from the vendor on this. I don't know what
their source looks like, being just a local admin of one of their client
sites -- and probably getting a bit too involved in things I have no
control over.
> ... the whole concept of locks is sort of obsolete since PostgreSQL uses
> multiversion concurrency control which does not require locks (loosely
> speaking)...
Maybe this app is married to the lock concept because it has to work in
a roughly equivalent way with various underlying database layers, and so
tries to cling to the mechanisms they have in common. The concurrency
control idea makes a lot of sense, and I wouldn't be surprised if they
are not aware of it or don't understand it.
Also they have things set up so that maybe a "session" ends up not
meaning what it should. For instance, although the application has its
own separate users and means of authenticating them, I am pretty sure it
makes all postgres queries as a single generic user.
Thanks for taking the trouble to reply. I'll pass along all the
information I can, and try to light a constructive fire under these guys.
-- Mark
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2004-07-08 22:58:06 | [Patch] First buffer overflow fixes |
Previous Message | Peter Eisentraut | 2004-07-08 18:08:50 | Re: psqlodbc versioning |