Horton
Menu

Thread

  1. pg_dump failing on LinuxPPC

    PostgreSQL Bugs List <pgsql-bugs@postgresql.org> — 2001-02-22T00:41:34Z

    Stu Coates (pgsql@stucoates.com) reports a bug with a severity of 1
The lower the number the more severe it is.

Short Description
pg_dump failing on LinuxPPC

Long Description
pg_dump is failing (although differently from 7.0) on LinuxPPC, see example for details.

Hardware:

Apple Powermac G3 B&W 400Mhz
512MB RAM

Software:

LinuxPPC 2000, kernel: 2.2.15pre3 (standard)
PostgreSQL 7.1beta4 on powerpc-unknown-linux-gnu, compiled by GCC 2.95.2

Compiled from source, using default options.


Sample Code
$ createdb foo
$ pg_dump foo
getAggregates(): SELECT failed.  Explanation from backend: 'ERROR:  Attribute 'aggtransfn1' not found
'.
$


No file was uploaded with this report

  2. Re: pg_dump failing on LinuxPPC

    Tom Lane <tgl@sss.pgh.pa.us> — 2001-02-22T03:58:08Z

    pgsql-bugs@postgresql.org writes:
> getAggregates(): SELECT failed.  Explanation from backend: 'ERROR:  Attribute 'aggtransfn1' not found'.

Looks like you're trying to run a 6.5-or-older pg_dump against a 7.1 backend.
Check your PATH.

			regards, tom lane

  3. Re: pg_dump failing on LinuxPPC

    Stu Coates <stu@stucoates.com> — 2001-02-22T08:04:15Z

    Tom Lane wrote:
> 
> Looks like you're trying to run a 6.5-or-older pg_dump against a 7.1 backend.
> Check your PATH.

Boy am I red faced... I was forgetting that LinuxPPC2000 comes with
PostgreSQL installed... oh well, it was late! ;-(

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.

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.

  4. Re: pg_dump failing on LinuxPPC

    Tom Lane <tgl@sss.pgh.pa.us> — 2001-02-23T22:55:18Z

    Stu Coates <stu@StuCoates.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.

			regards, tom lane

  5. Lock Detection (was: pg_dump failing on LinuxPPC)

    Stu Coates <stu@stucoates.com> — 2001-02-24T08:03:13Z

    Tom Lane wrote:
> 
> Stu Coates <stu@StuCoates.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.

  6. Re: Lock Detection (was: pg_dump failing on LinuxPPC)

    Tom Lane <tgl@sss.pgh.pa.us> — 2001-02-24T15:56:08Z

    Stu Coates <stu@StuCoates.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

  7. Re: Lock Detection (was: pg_dump failing on LinuxPPC)

    Stu Coates <stu@stucoates.com> — 2001-02-25T15:25:16Z

    Tom Lane wrote:
> 
> Stu Coates <stu@StuCoates.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.

I realize that PostgreSQL does not support nested transactions.

For the project I'm currently working on I'd like my unit of work to be:

begin transaction
  lock all of the entities (rows) that I'll require in this transaction
  if any lock fails then abort transaction (rollback)

  perform operations

end transaction (commit)

...and then be able to perform this unit of work for a whole list of
work units as fast as I can without waiting for locks to be released by
other processes.  If any of the units of work cannot be completed due to
existing locks then they will be retried at a later time.  At the moment
I'd have to maintain my own lock lists and perform atomic operations on
that to get the behavior that I require.  Can you suggest another way
using the PostgreSQL lock manager?

Regards,

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.