Skip site navigation (1) Skip section navigation (2)

Lock Detection (was: pg_dump failing on LinuxPPC)

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: (view raw or whole 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 Coates
Chelmsford, England U.K.

The day Microsoft makes something that doesn't suck is probably the day
they start making vacuum cleaners.

In response to


pgsql-bugs by date

Next:From: Tatsuo IshiiDate: 2001-02-24 13:05:43
Subject: Re: Sequence of characters not supported by psql/pg_dump
Previous:From: Tom LaneDate: 2001-02-24 00:41:23
Subject: Re: Receiving "No such file or directory" error from the database

Privacy Policy | About PostgreSQL
Copyright © 1996-2015 The PostgreSQL Global Development Group