From: | Stu Coates <stu(at)StuCoates(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql(at)StuCoates(dot)com, pgsql-bugs(at)postgresql(dot)org, Philip Warner <pjw(at)rhyme(dot)com(dot)au> |
Subject: | Lock Detection (was: pg_dump failing on LinuxPPC) |
Date: | 2001-02-24 08:03:13 |
Message-ID: | 3A976AC1.9370CDCF@StuCoates.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Tom Lane wrote:
>
> Stu Coates <stu(at)StuCoates(dot)com> writes:
> > Anyway, I've sorted my obsolete version problem, and have discovered
> > another. Attached is a short shell script that causes pg_dump to core
> > dump whilst trying to dump a single, quite simple, table.
>
> Fix committed --- but it just missed the boat for 7.1beta5 :-(. Please
> try current CVS or tomorrow's snapshot, instead.
Thanks for that Tom, I'll give it a shot later.
On a slightly different matter:
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?
Stu.
--
Stu Coates
Chelmsford, England U.K.
http://www.StuCoates.com/
The day Microsoft makes something that doesn't suck is probably the day
they start making vacuum cleaners.
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2001-02-24 13:05:43 | Re: Sequence of characters not supported by psql/pg_dump |
Previous Message | Tom Lane | 2001-02-24 00:41:23 | Re: Receiving "No such file or directory" error from the database |