Thread: pg_dump failing on LinuxPPC
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
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
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.
Attachment
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
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
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.
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.