Just as a suggestion: In most of my applications, we have a security
layer
which is implemented through server-side functions. These functions
keep a
table updated which contains:
lock_table
record_id
lock_user
time_locked
That's an excellent and even portable idea.
This allows us to
I am trying to emulate a pessimistic locking system you would find in
an
old school database file system, for example cobol. Generally, when a
cobol program tries to read a record that is locked by somebody else,
the read fails and either a message is displayed by the user or a
error
That's my fallback position. Obviously, this will lead to false
positives depending on server load. In my case, I'm targeting between
30-50 users so its likely to throw timeouts for various reasons other
than locks even though my queries of interest are generally select a
from b where id = c
That's my fallback position. Obviously, this will lead to false
positives depending on server load. In my case, I'm targeting between
30-50 users so its likely to throw timeouts for various reasons other
than locks even though my queries of interest are generally select a
from b where id
I was referring to 10.3 in the administrator's guide, regarding the
pg_lock view. According to the documentation, the view only contains
table level locks. However, the view also contains an xid for
transactions. The unclear part, at least to me, was what the role of
the xid was in the view and
Merlin Moncure [EMAIL PROTECTED] writes:
In my case, being able to view outstanding row level locks would be
enormously useful.
The only way to do that would be to grovel through every table in the
database, looking for rows that are marked locked by transactions that
are still alive.
A
In my case, being able to view outstanding row level locks would be
enormously useful. I'm assuming this is not possible for structural or
Agreed -- but they're stored on the row themselves. You might be able
to write a function which executes dirty reads on the table and tells
you if the row
Rod Taylor [EMAIL PROTECTED] writes:
Agreed -- but they're stored on the row themselves. You might be able
to write a function which executes dirty reads on the table and tells
you if the row is locked or not, but it's not going to be simple.
Actually, I don't think you need a dirty read at
On Thu, 2003-02-27 at 15:02, Tom Lane wrote:
Rod Taylor [EMAIL PROTECTED] writes:
Agreed -- but they're stored on the row themselves. You might be able
to write a function which executes dirty reads on the table and tells
you if the row is locked or not, but it's not going to be simple.
This directly answers my question (wasn't previously aware that xid
could be queried out in such a useful fashion). Not only does this
accomplish what I need, but now allows me to not use select ... for
update and stick with a transaction based locking mechanism. The 'Why'
isn't that
Merlin,
Just as a suggestion: In most of my applications, we have a security layer
which is implemented through server-side functions. These functions keep a
table updated which contains:
lock_table
record_id
lock_user
time_locked
This allows us to avoid nasty your update cannot be
I am trying to emulate a pessimistic locking system you would find in an
old school database file system, for example cobol. Generally, when a
cobol program tries to read a record that is locked by somebody else,
the read fails and either a message is displayed by the user or a error
handling
12 matches
Mail list logo
