Tom Lane wrote:
>
> Stu Coates <[EMAIL PROTECTED]> 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 "N
Tom Lane wrote:
>
> Stu Coates <[EMAIL PROTECTED]> 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 i
Stu Coates <[EMAIL PROTECTED]> 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 t
Stu Coates <[EMAIL PROTECTED]> 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.1b
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 di
[EMAIL PROTECTED] 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
Stu Coates ([EMAIL PROTECTED]) 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
