Re: Can pessimistic locking be emulated?

From: Christoph Haller <ch(at)rodos(dot)fzk(dot)de>
To: pgsql-hackers(at)postgresql(dot)org
Cc: merlin(dot)moncure(at)rcsonline(dot)com
Subject: Re: Can pessimistic locking be emulated?
Date: 2003-02-27 12:33:11
Message-ID: 3E5E0587.38535C8@rodos.fzk.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>
> 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 procedure is executed. I would like to emulate this behavior

> for legacy code while using mvcc for newer procedures I write.
>
> 4 questions:
> 1. Can you query if a tuple is locked by another transaction (the
> documentation unclearly suggests this can't be done via the pg_lock
> view) before executing select for update...?
> 2. If so, is this reasonable efficient to do, i.e. straight join on
> oid/xid?
> 3. If so, is this possible to query without a race condition regarding

> the lock status?
> 4. If so, is this likely to be possible in future versions of postgres

> without non-trivial changes?
>
> In other words, if User B attempts to select for update a record that
> user A has selected for update, it would be nice if User B's query
would
> fail with a NOTICE to act upon.
>
No idea if this is of any help, but you may have a look into
PostgreSQL 7.3 Documentation
3.4. Run-time Configuration
STATEMENT_TIMEOUT (integer)
Aborts any statement that takes over the specified number of
milliseconds. A value of zero turns off the timer.

Regards, Christoph

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Buttafuoco 2003-02-27 12:34:12 Re: Index File growing big.
Previous Message pgsql-bugs 2003-02-27 11:35:19 Bug #904: Deallocating of prepared statement in ECPG at COMMIT