From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stu Coates <stu(at)StuCoates(dot)com> |
Cc: | pgsql(at)StuCoates(dot)com, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: Lock Detection (was: pg_dump failing on LinuxPPC) |
Date: | 2001-02-24 15:56:08 |
Message-ID: | 11833.983030168@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Stu Coates <stu(at)StuCoates(dot)com> writes:
> I come from an Oracle background where I can lock an item of data by
> performing a "SELECT FOR UPDATE" on the row. This is also implemented
> in PostgreSQL. A quite useful feature Oracle does have is the ability
> to add a "NOWAIT" clause to the end of the command which will cause an
> exception if the item of data already has a lock taken out on it.
> AFAIK, this is not implemented in PostgreSQL. I did see a note that
> lock timeouts are not implemented, but if "NOWAIT" is added the
> application developer could implement/fudge timeouts him/herself. Would
> this be relatively easy to add?
It'd be possible, but not particularly easy; anything that involves
changing parse/plan trees is tedious. Moreover, I doubt that it'd be
especially useful given the lack of nested transactions in Postgres.
You'll have to make a lot better case than the above if you want to
get anyone excited about the idea.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Солодовников Константин | 2001-02-24 23:47:26 | Strangeness/bug when working with my own datatype in PostgreSQL |
Previous Message | Tatsuo Ishii | 2001-02-24 13:05:43 | Re: Sequence of characters not supported by psql/pg_dump |