How to find out about the functions supported in Postgres 8

laurie.burrow@powerconv.alstom.com wrote:

In another thread (Re: [GENERAL] Return value of 'serial' column on insert)
Bruno Wolff wrote

...

You can use the currval function to get the id. Normally the sequence
will have a name like table_column_seq. In 8.0, there is a function
you can use to get the sequence name, which is a bit more robust than
hard coding it.

This sounds well useful. How do I find out what the functions available in
Postgres 8 are, and what their usage and calling parameters are?

The manuals are online at http://www.postgresql.org/ and come with most
installations.

As a quick reminder, you can do "\df foo*" in psql to check functions
that start with "foo".

--
Richard Huxton
Archonet Ltd

It seems that contrib/intagg crashes my server :
-------------------------------------------------------------------------
select int_agg_final_array(1);
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
-------------------------------------------------------------------------
Here's the logfile :

TRACE: le systeme de bases de donnees est pret
TRACE: processus serveur (PID 26882) a ete arrete par le signal 11
TRACE: Arret des autres processus serveur actifs
FATAL: Le systeme de bases de donnees est en cours de restauration
TRACE: Tous les processus serveur se sont arretes, reinitialisation
TRACE: le systeme de bases de donnees a ete interrompu a 2005-01-27
17:22:48 CET
TRACE: l'enregistrement du point de verification est a 1/F3854A94
TRACE: re-execution de l'enregistrement a 1/F3854A94 ; l'annulation de
l'enregistrement est a 0/0 ; arret TRUE
TRACE: prochain identifiant de transaction : 5800 ; prochain OID : 4533584
TRACE: le systeme de bases de donnees n'a pas ete arrete proprement ;
restauration automatique en cours
TRACE: enregistrement de longueur nulle sur 1/F3854AD0
TRACE: la re-execution n'est pas requise
TRACE: le systeme de bases de donnees est pret

What do you think ?

[I've Cc'ed pgsql-bugs and set the Reply-To header to that list.]

On Thu, Jan 27, 2005 at 05:26:26PM +0100, PFC wrote:

It seems that contrib/intagg crashes my server :
-------------------------------------------------------------------------
select int_agg_final_array(1);
server closed the connection unexpectedly

I see the same thing with PostgreSQL 8.0.0 (REL8_0_STABLE) on Solaris 9
and FreeBSD 4.11. Here's part of the backtrace from the core dump on
FreeBSD:

(gdb) bt
#0 0x285077f4 in ShrinkPGArray (p=0x1) at int_aggregate.c:130
#1 0x28507929 in int_agg_final_array (fcinfo=0xbfbfeb90) at int_aggregate.c:177
#2 0x8106db8 in ExecMakeFunctionResult (fcache=0x83410a0, econtext=0x83411e8,
isNull=0xbfbfecef "\b0����K\024\b�z3\b�\003", isDone=0x0) at execQual.c:1042
#3 0x8107583 in ExecEvalFunc (fcache=0x83410a0, econtext=0x83411e8,
isNull=0xbfbfecef "\b0����K\024\b�z3\b�\003", isDone=0x0) at execQual.c:1459
#4 0x8108beb in ExecEvalExprSwitchContext (expression=0x83410a0, econtext=0x83411e8,
isNull=0xbfbfecef "\b0����K\024\b�z3\b�\003", isDone=0x0) at execQual.c:2781
#5 0x8145353 in evaluate_expr (expr=0x8337ab8, result_type=1007) at clauses.c:2399

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/

I'm sorry, I forgot to say I had the bug with 8rc3, then installed 8.0.0
and it is still crashing.

On Thu, 27 Jan 2005 10:52:37 -0700, Michael Fuhr <mike@fuhr.org> wrote:

Michael Fuhr <mike@fuhr.org> writes:

On Thu, Jan 27, 2005 at 05:26:26PM +0100, PFC wrote:

It seems that contrib/intagg crashes my server :

I see the same thing with PostgreSQL 8.0.0 (REL8_0_STABLE) on Solaris 9
and FreeBSD 4.11.

The intagg source code says

NOTE: This module requires sizeof(void *) to be the same as sizeof(int)

which in English means "this ain't gonna work on 64-bit machines". I've
never bothered to look at it more closely than that ...

regards, tom lane

On Thu, Jan 27, 2005 at 02:22:36PM -0500, Tom Lane wrote:

Michael Fuhr <mike@fuhr.org> writes:

On Thu, Jan 27, 2005 at 05:26:26PM +0100, PFC wrote:

It seems that contrib/intagg crashes my server :

I see the same thing with PostgreSQL 8.0.0 (REL8_0_STABLE) on Solaris 9
and FreeBSD 4.11.

The intagg source code says

NOTE: This module requires sizeof(void *) to be the same as sizeof(int)

which in English means "this ain't gonna work on 64-bit machines". I've
never bothered to look at it more closely than that ...

Hmmm...the PostgreSQL binaries on my Solaris/sparc box are 32-bit
and the FreeBSD box is a 32-bit i386, yet both are susceptible to
the crash. On both boxes, a 32-bit program shows both sizeof(void *)
and sizeof(int) to be 4, so the problem doesn't appear to be due
to that necessary condition not being satisfied.

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I think it is an internal thing with gcc that the size of a pointer and
sizeof(int) are always the same, regardless of machine word size...
with a 64-bit binary, sizeof(int) and sizeof(void *) should both be 8,
which still causes them to be equal.

On Jan 27, 2005, at 2:38 PM, Michael Fuhr wrote:

On Thu, Jan 27, 2005 at 02:22:36PM -0500, Tom Lane wrote:

Michael Fuhr <mike@fuhr.org> writes:

On Thu, Jan 27, 2005 at 05:26:26PM +0100, PFC wrote:

It seems that contrib/intagg crashes my server :

I see the same thing with PostgreSQL 8.0.0 (REL8_0_STABLE) on
Solaris 9
and FreeBSD 4.11.

The intagg source code says

NOTE: This module requires sizeof(void *) to be the same as
sizeof(int)

which in English means "this ain't gonna work on 64-bit machines".
I've
never bothered to look at it more closely than that ...

Hmmm...the PostgreSQL binaries on my Solaris/sparc box are 32-bit
and the FreeBSD box is a 32-bit i386, yet both are susceptible to
the crash. On both boxes, a 32-bit program shows both sizeof(void *)
and sizeof(int) to be 4, so the problem doesn't appear to be due
to that necessary condition not being satisfied.

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/

---------------------------(end of
broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

- -----------------------------------------------------------
Frank D. Engel, Jr. <fde101@fjrhome.net>

$ ln -s /usr/share/kjvbible /usr/manual
$ true | cat /usr/manual | grep "John 3:16"
John 3:16 For God so loved the world, that he gave his only begotten
Son, that whosoever believeth in him should not perish, but have
everlasting life.
$
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFB+UhH7aqtWrR9cZoRAnAFAJ43uG1sfDKrorDo17SoBW1+H8k7EQCfRvfH
7yQBTSKBiqkIdQ5Oh8tL2js=
=90y9
-----END PGP SIGNATURE-----

___________________________________________________________
$0 Web Hosting with up to 120MB web space, 1000 MB Transfer
10 Personalized POP and Web E-mail Accounts, and much more.
Signup at www.doteasy.com

Michael Fuhr <mike@fuhr.org> writes:

Hmmm...the PostgreSQL binaries on my Solaris/sparc box are 32-bit
and the FreeBSD box is a 32-bit i386, yet both are susceptible to
the crash.

On looking at it, the problem is that the functions are defined in such
a way that you can pass any random integer value to int_agg_final_array(),
and it'll try to interpret that as a pointer. So (a) it definitely
cannot work on 64-bit-pointer machines, and (b) it's trivial to crash it
by passing a number that's not a pointer.

The code should be rewritten by someone who has the skill to program
their way out of a paper bag :-( but I don't think there is time for a
proper fix right now. What I'm inclined to do as a stopgap is just to
revoke all privileges from public on the two component functions of the
aggregate, since there is no particularly good reason to allow them to
be called directly anyway.

regards, tom lane

On Thu, Jan 27, 2005 at 03:00:06PM -0500, Frank D. Engel, Jr. wrote:

I think it is an internal thing with gcc that the size of a pointer and
sizeof(int) are always the same, regardless of machine word size...
with a 64-bit binary, sizeof(int) and sizeof(void *) should both be 8,
which still causes them to be equal.

Not with gcc 3.4.2 on Solaris 9/sparc -- maybe you're thinking of
sizeof(long).

% cat foo.c
#include <stdio.h>

int
main(void)
{
printf("sizeof(void *) = %d\n", sizeof(void *));
printf("sizeof(int) = %d\n", sizeof(int));
printf("sizeof(long) = %d\n", sizeof(long));
return 0;
}

% gcc -m32 -o foo foo.c
% ./foo
sizeof(void *) = 4
sizeof(int) = 4
sizeof(long) = 4

% gcc -m64 -o foo foo.c
% ./foo
sizeof(void *) = 8
sizeof(int) = 4
sizeof(long) = 8

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/

"Frank D. Engel, Jr." <fde101@fjrhome.net> writes:

I think it is an internal thing with gcc that the size of a pointer and
sizeof(int) are always the same, regardless of machine word size...
with a 64-bit binary, sizeof(int) and sizeof(void *) should both be 8,
which still causes them to be equal.

The above statement might be true with respect to long, but not int.

regards, tom lane

Frank D. Engel, Jr. wrote:

I think it is an internal thing with gcc that the size of a pointer
and
sizeof(int) are always the same, regardless of machine word size...
with a 64-bit binary, sizeof(int) and sizeof(void *) should both be 8,
which still causes them to be equal.

On AMD64, gcc produced: int 4 long 8 pointer 8
--
Guy Rouillier

On Thu, Jan 27, 2005 at 03:07:39PM -0600, Guy Rouillier wrote:

Frank D. Engel, Jr. wrote:

I think it is an internal thing with gcc that the size of a pointer
and
sizeof(int) are always the same, regardless of machine word size...
with a 64-bit binary, sizeof(int) and sizeof(void *) should both be 8,
which still causes them to be equal.

On AMD64, gcc produced: int 4 long 8 pointer 8

And this is as it's supposed to be. 32-bit architectures are usually
ILP32 (ints, longs and pointers are 32 bits) whereas 64-bit
architectures are generally LP64 (longs and pointers are 64 bits but
ints are *not*).

I'm sure you could search for reasons why this is but this is how it
is.

Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/