[HACKERS] UnixWare 7.1.3 (BETA), C99 compiler, current CVS, error...
Without specifying the -Xb switch to kill the C99 interpretation of inline, I get the following from current CVS: UX:acomp: ERROR: tuplesort.c, line 1854: inline functions cannot use static identifier: myFunctionCall2 UX:acomp: ERROR: tuplesort.c, line 1856: inline functions cannot use static identifier: myFunctionCall2 UX:acomp: ERROR: tuplesort.c, line 1870: inline functions cannot use static identifier: myFunctionCall2 UX:acomp: ERROR: tuplesort.c, line 1872: inline functions cannot use static identifier: myFunctionCall2 UX:acomp: ERROR: tuplesort.c, line 1885: inline functions cannot use static identifier: myFunctionCall2 UX:acomp: ERROR: tuplesort.c, line 1897: inline functions cannot use static identifier: myFunctionCall2 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] UnixWare 7.1.3 (BETA), compile error (with cc -Xb)
With cc -Xb, we get farther, but still die (CURRENT CVS):
cc -Xb -O -g -K PIC -I../../../../../../src/include -I/usr/local/include -c -o
ascii_and_mic.o ascii_and_mic.c
UX:cc: WARNING: debugging and optimization mutually exclusive; -O disabled
UX:acomp: ERROR: ascii_and_mic.c, line 19: syntax error, probably missing ,, ;
or =
UX:acomp: ERROR: ascii_and_mic.c, line 19: only register valid as formal parameter
storage class
UX:acomp: ERROR: ascii_and_mic.c, line 19: parameter not in identifier list:
pg_finfo_mic_to_ascii
UX:acomp: ERROR: ascii_and_mic.c, line 19: parameter not in identifier list:
pg_finfo_mic_to_ascii
UX:acomp: ERROR: ascii_and_mic.c, line 19: Syntax error before or at: {
UX:acomp: ERROR: ascii_and_mic.c, line 19: only register valid as formal parameter
storage class
UX:acomp: ERROR: ascii_and_mic.c, line 19: parameter not in identifier list: my_finfo
UX:acomp: ERROR: ascii_and_mic.c, line 19: cannot initialize parameter: my_finfo
UX:acomp: WARNING: ascii_and_mic.c, line 19: statement not reached
UX:acomp: ERROR: ascii_and_mic.c, line 19: Syntax error before or at: return
UX:acomp: ERROR: ascii_and_mic.c, line 19: parameter not in identifier list: my_finfo
UX:acomp: ERROR: ascii_and_mic.c, line 19: only register valid as formal parameter
storage class
UX:acomp: ERROR: ascii_and_mic.c, line 21: parameter not in identifier list:
no_such_variable
UX:acomp: ERROR: ascii_and_mic.c, line 21: only register valid as formal parameter
storage class
UX:acomp: ERROR: ascii_and_mic.c, line 21: parameter not in identifier list:
ascii_to_mic
UX:acomp: ERROR: ascii_and_mic.c, line 22: only register valid as formal parameter
storage class
UX:acomp: ERROR: ascii_and_mic.c, line 22: parameter not in identifier list:
mic_to_ascii
UX:acomp: ERROR: ascii_and_mic.c, line 37: parameter not in identifier list:
ascii_to_mic
UX:acomp: ERROR: ascii_and_mic.c, line 37: Syntax error before or at: {
UX:acomp: ERROR: ascii_and_mic.c, line 38: parameter not in identifier list: src
UX:acomp: ERROR: ascii_and_mic.c, line 38: cannot initialize parameter: src
UX:acomp: ERROR: ascii_and_mic.c, line 38: undefined symbol: fcinfo
UX:acomp: ERROR: ascii_and_mic.c, line 38: left operand of - must be pointer to
struct/union
UX:acomp: WARNING: ascii_and_mic.c, line 38: assignment type mismatch
UX:acomp: ERROR: ascii_and_mic.c, line 39: parameter not in identifier list: dest
UX:acomp: ERROR: ascii_and_mic.c, line 39: cannot initialize parameter: dest
UX:acomp: ERROR: ascii_and_mic.c, line 39: left operand of - must be pointer to
struct/union
UX:acomp: WARNING: ascii_and_mic.c, line 39: assignment type mismatch
UX:acomp: ERROR: ascii_and_mic.c, line 40: parameter not in identifier list: len
UX:acomp: ERROR: ascii_and_mic.c, line 40: cannot initialize parameter: len
UX:acomp: ERROR: ascii_and_mic.c, line 40: left operand of - must be pointer to
struct/union
UX:acomp: ERROR: ascii_and_mic.c, line 42: Syntax error before or at: do
UX:acomp: ERROR: ascii_and_mic.c, line 42: Syntax error before or at:
UX:acomp: ERROR: ascii_and_mic.c, line 42: Syntax error before or at: (
UX:acomp: ERROR: ascii_and_mic.c, line 42: function cannot return function or array
UX:acomp: ERROR: ascii_and_mic.c, line 42: parameter not in identifier list: int32
UX:acomp: ERROR: ascii_and_mic.c, line 42: Syntax error before or at:
UX:acomp: ERROR: ascii_and_mic.c, line 42: parameter not in identifier list:
PG_SQL_ASCII
UX:acomp: ERROR: ascii_and_mic.c, line 42: parameter not in identifier list:
ExceptionalCondition
UX:acomp: WARNING: ascii_and_mic.c, line 42: syntax error: empty declaration
UX:acomp: WARNING: ascii_and_mic.c, line 42: syntax error: empty declaration
UX:acomp: ERROR: ascii_and_mic.c, line 43: Syntax error before or at:
UX:acomp: ERROR: ascii_and_mic.c, line 43: Syntax error before or at: (
UX:acomp: ERROR: ascii_and_mic.c, line 43: function cannot return function or array
UX:acomp: ERROR: ascii_and_mic.c, line 43: parameter not in identifier list: int32
UX:acomp: ERROR: ascii_and_mic.c, line 43: Syntax error before or at:
UX:acomp: ERROR: ascii_and_mic.c, line 43: parameter not in identifier list:
PG_MULE_INTERNAL
UX:acomp: ERROR: ascii_and_mic.c, line 43: parameter not in identifier list:
ExceptionalCondition
UX:acomp: WARNING: ascii_and_mic.c, line 43: syntax error: empty declaration
UX:acomp: WARNING: ascii_and_mic.c, line 43: syntax error: empty declaration
UX:acomp: ERROR: ascii_and_mic.c, line 44: Syntax error before or at:
UX:acomp: ERROR: ascii_and_mic.c, line 44: parameter not in identifier list:
ExceptionalCondition
UX:acomp: WARNING: ascii_and_mic.c, line 44: syntax error: empty declaration
UX:acomp: WARNING: ascii_and_mic.c, line 44: syntax error: empty declaration
UX:acomp: WARNING: ascii_and_mic.c, line 46: function prototype parameters must have
types
UX:acomp: ERROR: ascii_and_mic.c, line 46: parameter not in identifier list:
pg_ascii2mic
UX:acomp: ERROR: ascii_and_mic.c, line 48: Syntax error
Re: [HACKERS] UnixWare 7.1.3 (BETA), C99 compiler, current CVS, error...
Larry Rosenman [EMAIL PROTECTED] writes: Without specifying the -Xb switch to kill the C99 interpretation of inline, I get the following from current CVS: UX:acomp: ERROR: tuplesort.c, line 1854: inline functions cannot use static identifier: myFunctionCall2 I don't understand what it's unhappy about. My C99 draft sez [#6] Any function with internal linkage can be an inline function. so the text of the message is surely not what they are really complaining about? Or is the compiler broken? regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] UnixWare 7.1.3 (BETA), compile error (with cc -Xb)
Larry Rosenman [EMAIL PROTECTED] writes: With cc -Xb, we get farther, but still die (CURRENT CVS): cc -Xb -O -g -K PIC -I../../../../../../src/include -I/usr/local/include -c -o ascii_and_mic.o ascii_and_mic.c UX:cc: WARNING: debugging and optimization mutually exclusive; -O disabled UX:acomp: ERROR: ascii_and_mic.c, line 19: syntax error, probably missing ,, ; or = This one is my fault: when I hacked up PG_FUNCTION_INFO_V1 yesterday, I neglected to check to be sure that *every* use had a semicolon after it. Just discovered that a few minutes ago myself. Fix is committed. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] UnixWare 7.1.3 (BETA), C99 compiler, current CVS,
On Sat, 2002-10-26 at 10:07, Tom Lane wrote: Larry Rosenman [EMAIL PROTECTED] writes: Without specifying the -Xb switch to kill the C99 interpretation of inline, I get the following from current CVS: UX:acomp: ERROR: tuplesort.c, line 1854: inline functions cannot use static identifier: myFunctionCall2 I don't understand what it's unhappy about. My C99 draft sez [#6] Any function with internal linkage can be an inline function. so the text of the message is surely not what they are really complaining about? Or is the compiler broken? I'll ask, it is Beta (although the Compiler has done this since the C99 functionality was added, and it causes a LOT of open source stuff to require -Xb). regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Request for supported platforms
Updated: http://candle.pha.pa.us/main/writings/pgsql/sgml/supported-platforms.html --- Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Folks. start sending in those plaform reports, OS name and version number please. I've checked CVS tip on: HPUX 10.20, using both gcc and vendor's cc PPC Linux Mac OS X 10.1 regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Request for supported platforms
Updated: http://candle.pha.pa.us/main/writings/pgsql/sgml/supported-platforms.html --- Doug McNaught wrote: Doug McNaught [EMAIL PROTECTED] writes: OK, compile went fine, but I get multiple regression test failures: test geometry ... FAILED After realizing that my disk had filled up (thanks Alvaro) I reran the tests and 'geometry' is the only failure. I'm guessing this is due to floating-point differences? If this is OK, then Linux/Sparc (Debian 3.0) is a PASS. -Doug -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] beta3 packaged ...
Please check it and confirm ... I believe everything, includin the docs, should be right on this ... if not, I'm going to repackage before announcing ... ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Request for supported platforms
On Sat, Oct 26, 2002 at 04:01:17PM -0400, Bruce Momjian wrote: Updated: http://candle.pha.pa.us/main/writings/pgsql/sgml/supported-platforms.html Linux 2.4 on IA32 passes also. -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) La felicidad no es mañana. La felicidad es ahora ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] idle connection timeout ...
Bruno Wolff III wrote: On Sat, Oct 26, 2002 at 01:04:55 -0400, Bruce Momjian [EMAIL PROTECTED] wrote: The per db/user stuff is stored in the pg_database/pg_shadow tables per row, so they exist in permanent storage. I have a question about this. This stuff is per user OR per db right? When I see per db/user I get the impression that users can have different settings depending on which db they connect to. But looking at alter database and alter user it looks like settings are per database or per user, but there isn't a way to (in general) set something that applies to a particular user when connecting to a particular database. If there is a way to do that, I would be interested in a hint where to look in the documentation. You are right, there isn't a per/db-user combination setting. I think one is done before the other, so you could try to set things that way, maybe in a plpgsql procedure. I think you could do SELECT db_user_set(); and have that function do that sets for you. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] UnixWare 7.1.3: with current CVS, and cc -Xb.,..
Updated: http://candle.pha.pa.us/main/writings/pgsql/sgml/supported-platforms.html --- Larry Rosenman wrote: We pass all regression test. this is UnixWare 7.1.3, with the native cc compiler. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] assignment type mismatch complaints
Can you send over a list of the errors and we will check them out. --- Larry Rosenman wrote: How concerned are we about assignment type mismatch warnings? I got a bunch in the mb stuff, and some in other places from the UnixWare 7.1.3 compiler. We still pass all regression tests. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Request for supported platforms
Ports list updated: http://candle.pha.pa.us/main/writings/pgsql/sgml/supported-platforms.html --- Alvaro Herrera wrote: On Sat, Oct 26, 2002 at 04:01:17PM -0400, Bruce Momjian wrote: Updated: http://candle.pha.pa.us/main/writings/pgsql/sgml/supported-platforms.html Linux 2.4 on IA32 passes also. -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) La felicidad no es ma?ana. La felicidad es ahora -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] UnixWare 7.1.3 (BETA), C99 compiler, current CVS, error...
Larry Rosenman [EMAIL PROTECTED] writes: so the text of the message is surely not what they are really complaining about? Or is the compiler broken? I'll ask, it is Beta (although the Compiler has done this since the C99 functionality was added, and it causes a LOT of open source stuff to require -Xb). After reading a little further, it seems that the brain damage is in the standard, not the compiler :-(. It looks like C99's notion of a function that is both global and inline is that you must provide *two* definitions of the function, one marked inline and one not; moreover, these must appear in separate translation units. What in the world were those people smoking? That's a recipe for maintenance problems (edit one definition, forget to edit the other), not to mention completely at variance with the de facto standard behavior of inline that's been around for a long time. My inclination is to change the code for ApplySortFunction to look like #if defined(__GNUC__) __inline__ #endif int32 ApplySortFunction so that the inline optimization only gets done for gcc, which we know interprets inline sanely. Anyone see a better answer? regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Request for supported platforms
Tom Lane [EMAIL PROTECTED] writes: Bruce Momjian [EMAIL PROTECTED] writes: Folks. start sending in those plaform reports, OS name and version number please. I've checked CVS tip on: HPUX 10.20, using both gcc and vendor's cc PPC Linux Mac OS X 10.1 I get the following on Linux/Sparc, Debian 3.0: make[3]: Entering directory `/home/doug/src/pgsql/src/backend/utils/mb/conversion_procs/ascii_and_mic' gcc -O2 -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -I../../../../../../src/include -c -o ascii_and_mic.o ascii_and_mic.c ascii_and_mic.c:19: syntax error before `extern' ascii_and_mic.c:21: syntax error before `extern' make[3]: *** [ascii_and_mic.o] Error 1 make[3]: Leaving directory `/home/doug/src/pgsql/src/backend/utils/mb/conversion_procs/ascii_and_mic' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/doug/src/pgsql/src/backend/utils/mb/conversion_procs' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/doug/src/pgsql/src' make: *** [all] Error 2 My gcc version: doug@varsoon:~/src/pgsql$ gcc -v Reading specs from /usr/lib/gcc-lib/sparc-linux/2.95.4/specs gcc version 2.95.4 20011002 (Debian prerelease) This is CVS tip as of about 11:30 EST Saturday. Looking into it, we have in ascii_and_mic.c: PG_FUNCTION_INFO_V1(ascii_to_mic) PG_FUNCTION_INFO_V1(mic_to_ascii) Putting a semicolon after each such line fixes that compile, but there are other files under conversion_procs with the same problem. Is my gcc not expanding the macro properly? -Doug ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Request for supported platforms
Doug McNaught [EMAIL PROTECTED] writes: make[3]: Entering directory `/home/doug/src/pgsql/src/backend/utils/mb/conversion_procs/ascii_and_mic' gcc -O2 -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -I../../../../../../src/include -c -o ascii_and_mic.o ascii_and_mic.c ascii_and_mic.c:19: syntax error before `extern' ascii_and_mic.c:21: syntax error before `extern' That should be fixed as of now. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Request for supported platforms
Tom Lane [EMAIL PROTECTED] writes: Doug McNaught [EMAIL PROTECTED] writes: make[3]: Entering directory `/home/doug/src/pgsql/src/backend/utils/mb/conversion_procs/ascii_and_mic' gcc -O2 -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -I../../../../../../src/include -c -o ascii_and_mic.o ascii_and_mic.c ascii_and_mic.c:19: syntax error before `extern' ascii_and_mic.c:21: syntax error before `extern' That should be fixed as of now. OK, compile went fine, but I get multiple regression test failures: test geometry ... FAILED select_views ... FAILED foreign_key ... FAILED limit... FAILED plpgsql ... FAILED copy2... FAILED temp ... FAILED domain ... FAILED rangefuncs ... FAILED prepare ... FAILED without_oid ... FAILED conversion ... FAILED truncate ... FAILED alter_table ... FAILED I have attached a gzipped copy of regression.diffs. Let me know if I can supply any other help. -Doug regression.diffs.gz Description: regression diffs ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] UnixWare 7.1.3: with current CVS, and cc -Xb.,..
We pass all regression test. this is UnixWare 7.1.3, with the native cc compiler. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] assignment type mismatch complaints
How concerned are we about assignment type mismatch warnings? I got a bunch in the mb stuff, and some in other places from the UnixWare 7.1.3 compiler. We still pass all regression tests. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Request for supported platforms
Bruce Momjian [EMAIL PROTECTED] writes: Folks. start sending in those plaform reports, OS name and version number please. I've checked CVS tip on: HPUX 10.20, using both gcc and vendor's cc PPC Linux Mac OS X 10.1 regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Request for supported platforms
On 26 Oct 2002, Doug McNaught wrote: Tom Lane [EMAIL PROTECTED] writes: Doug McNaught [EMAIL PROTECTED] writes: make[3]: Entering directory `/home/doug/src/pgsql/src/backend/utils/mb/conversion_procs/ascii_and_mic' gcc -O2 -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -I../../../../../../src/include -c -o ascii_and_mic.o ascii_and_mic.c ascii_and_mic.c:19: syntax error before `extern' ascii_and_mic.c:21: syntax error before `extern' That should be fixed as of now. OK, compile went fine, but I get multiple regression test failures: test geometry ... FAILED select_views ... FAILED foreign_key ... FAILED limit... FAILED plpgsql ... FAILED copy2... FAILED temp ... FAILED domain ... FAILED rangefuncs ... FAILED prepare ... FAILED without_oid ... FAILED conversion ... FAILED truncate ... FAILED alter_table ... FAILED I have attached a gzipped copy of regression.diffs. Let me know if I can supply any other help. The geometry one looked like rounding issues. Did you run out of space on where the data directory was mounted? At least some of the other errors were complaining about no space left on device. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Request for supported platforms
Doug McNaught [EMAIL PROTECTED] writes: OK, compile went fine, but I get multiple regression test failures: test geometry ... FAILED After realizing that my disk had filled up (thanks Alvaro) I reran the tests and 'geometry' is the only failure. I'm guessing this is due to floating-point differences? If this is OK, then Linux/Sparc (Debian 3.0) is a PASS. -Doug ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] UnixWare 7.1.3: with current CVS, and cc -Xb.,..
On Sat, 2002-10-26 at 15:11, Bruce Momjian wrote: Updated: http://candle.pha.pa.us/main/writings/pgsql/sgml/supported-platforms.html the illustrious marketing folks at The SCO group (nee Caldera) have renamed this OS back to UnixWare. You may want to change the first column back to UnixWare. (and footnote that OpenUNIX 8.0.0 is really UnixWare 7.1.2). --- Larry Rosenman wrote: We pass all regression test. this is UnixWare 7.1.3, with the native cc compiler. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] UnixWare 7.1.3: with current CVS, and cc -Xb.,..
Update as you suggested: http://candle.pha.pa.us/main/writings/pgsql/sgml/supported-platforms.html --- Larry Rosenman wrote: On Sat, 2002-10-26 at 15:11, Bruce Momjian wrote: Updated: http://candle.pha.pa.us/main/writings/pgsql/sgml/supported-platforms.html the illustrious marketing folks at The SCO group (nee Caldera) have renamed this OS back to UnixWare. You may want to change the first column back to UnixWare. (and footnote that OpenUNIX 8.0.0 is really UnixWare 7.1.2). --- Larry Rosenman wrote: We pass all regression test. this is UnixWare 7.1.3, with the native cc compiler. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] assignment type mismatch complaints
Larry Rosenman [EMAIL PROTECTED] writes: How concerned are we about assignment type mismatch warnings? They're probably all char versus unsigned char complaints? There are a ton of them on compilers that care about it; most of 'em in the multibyte support. While it would be nice to clean up all that someday, I can't say that I think it's a really profitable use of time. One difficulty is that the obvious fix (add a bunch of casts) is probably a net degradation of the code. Explicit casts will hide mismatches that are a lot worse than char signedness, and so cluttering the code with them makes things more fragile IMHO. I think an acceptable fix would involve running around and changing datatype and function declarations; which is much more subtle and thought-requiring than throwing in a cast wherever the compiler burps. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] assignment type mismatch complaints
On Sat, 2002-10-26 at 18:27, Tom Lane wrote: Larry Rosenman [EMAIL PROTECTED] writes: How concerned are we about assignment type mismatch warnings? They're probably all char versus unsigned char complaints? Probably. The first few I looked at are PG_GETARG_CSTRING to unsigned char assignments. (I can send the whole list to either you, Tom, or the list). There are a ton of them on compilers that care about it; most of 'em in the multibyte support. While it would be nice to clean up all that someday, I can't say that I think it's a really profitable use of time. Ok, I understand that. It seems that there are a bunch, but they are just warnings. One difficulty is that the obvious fix (add a bunch of casts) is probably a net degradation of the code. Explicit casts will hide mismatches that are a lot worse than char signedness, and so cluttering the code with them makes things more fragile IMHO. I think an acceptable fix would involve running around and changing datatype and function declarations; which is much more subtle and thought-requiring than throwing in a cast wherever the compiler burps. Understand, and I don't expect it to happen in a beta test :-). regards, tom lane -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] idle connection timeout ...
On Fri, 25 Oct 2002, Bruce Momjian wrote: I need others wanting this before I can add something of this sophistication to TODO. Sounds cool to me, and would satisfy what I'm looking for, since it sounds like the same user could have different limits depending on the database they are/were connectin gto ... --- Mike Mascari wrote: Bruce Momjian wrote: Andrew Sullivan wrote: On Fri, Oct 25, 2002 at 11:02:48AM -0400, Tom Lane wrote: So? If it hits the installation-wide limit, you'll have the same problem; and at that point the (presumably runaway) app would have sucked up all the connections, denying service to other apps using other databases. I think Marc's point here is to limit his exposure to misbehavior of any one client app, in a database server that is serving multiple clients using multiple databases. That would indeed be a useful item. The only way to avoid such exposure right now is to run another back end. Added to TODO: * Allow limits on per-db/user connections Could I suggest that such a feature falls under the category of resource limits, and that the TODO should read something like: Implement the equivalent of Oracle PROFILEs. I think this would be a good project for 7.4. I'm not yet volunteering, but if I can wrap up my current project, I might be able to do it, depending upon the 7.4 target date. It would be: 1. A new system table: pg_profile 2. The attributes of the profiles would be: profname session_per_user cpu_per_session cpu_per_call connect_time idle_time logical_reads_per_session logical_reads_per_call 3. A new field would be added to pg_user/pg_shadow: profileid 4. A 'default' profile would be created when a new database is created with no resource limits. CREATE/ALTER user would be modified to allow for the specification of the profile. If no profile is provided, 'default' is assumed. 5. A new CREATE PROFILE/ALTER PROFILE/DROP PROFILE command set would be implemented to add/update/remove the tuples in pg_profiles. And according modification of pg_dump for dump/reload and psql for appropriate \ command. Example: CREATE PROFILE clerk IDLE_TIME 30; ALTER USER john PROFILE clerk; ALTER USER bob PROFILE clerk; or, for an ISP maybe: ALYTER PROFILE default IDLE_TIME 30; It seems like a nice project, particularly since it wouldn't affect anyone that doesn't want to use it. And whenever a new resource limitation issue arrises, such as PL/SQL recursion depth, a new attribute would be added to pg_profile to handle the limitation... Mike Mascari [EMAIL PROTECTED] -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Time for RC1 soon?
On Fri, 25 Oct 2002, Bruce Momjian wrote: We are putting out beta3 today or tomorrow. It seems we are ready to start considering an RC1 date, perhaps next Friday, November 1? tom is away for the week, so I wouldn't see anything earlier hten the week following tha t... --- P O S T G R E S Q L 7 . 3 O P E NI T E M S Current at ftp://momjian.postgresql.org/pub/postgresql/open_items. Required Changes --- Optional Changes Fix Linux + Perl 5.8.1 + _GNU_SOURCE problem Fix AIX + Large File + Flex problem Documentation Changes - -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Time for RC1 soon?
On Sat, 26 Oct 2002, Thomas Lockhart wrote: Seems like someone ought to issue a call for port reports. The supported platforms list hasn't been touched ... Good point. Thomas, can you take that on? No, at least not now. I'm not able to communicate reliably with the mailing lists, and so can not coordinate anything :( Not sure when or if that will be resolved, but I'll be out of town next week so... this should be fixed now tha I've removed the UCE controls ... as for being out of town next week, so is Tom Lane, so I don't feel tha that is a problem ... ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Time for RC1 soon?
On Sat, 26 Oct 2002, Thomas Lockhart wrote: ... and just out of curiosity, why does Bruce's message have a [HACKERS] tag in the subject line but my reply does not? It seems to be going through the same mailer but with different results... *puzzled look* both messages arrived here with the [HACKERS] headin gin the subject ... - Thomas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Time for RC1 soon?
Marc G. Fournier wrote: On Fri, 25 Oct 2002, Bruce Momjian wrote: We are putting out beta3 today or tomorrow. It seems we are ready to start considering an RC1 date, perhaps next Friday, November 1? tom is away for the week, so I wouldn't see anything earlier hten the week following tha t... I talked to him about that and we both feel this week while he is away will be pretty quiet and the only major thing left is making sure our docs are ready and we have enough platform reports. If we can go RC1 soon, we will keep beta to 2 months, which I think is acceptable. Tom returns Wednesday so let's see how we are this Thursday/Friday. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] idle connection timeout ...
Tom's idea of doing this as part of the already added per-user/per-db settings seems like a good direction to take. --- Marc G. Fournier wrote: On Fri, 25 Oct 2002, Bruce Momjian wrote: I need others wanting this before I can add something of this sophistication to TODO. Sounds cool to me, and would satisfy what I'm looking for, since it sounds like the same user could have different limits depending on the database they are/were connectin gto ... --- Mike Mascari wrote: Bruce Momjian wrote: Andrew Sullivan wrote: On Fri, Oct 25, 2002 at 11:02:48AM -0400, Tom Lane wrote: So? If it hits the installation-wide limit, you'll have the same problem; and at that point the (presumably runaway) app would have sucked up all the connections, denying service to other apps using other databases. I think Marc's point here is to limit his exposure to misbehavior of any one client app, in a database server that is serving multiple clients using multiple databases. That would indeed be a useful item. The only way to avoid such exposure right now is to run another back end. Added to TODO: * Allow limits on per-db/user connections Could I suggest that such a feature falls under the category of resource limits, and that the TODO should read something like: Implement the equivalent of Oracle PROFILEs. I think this would be a good project for 7.4. I'm not yet volunteering, but if I can wrap up my current project, I might be able to do it, depending upon the 7.4 target date. It would be: 1. A new system table: pg_profile 2. The attributes of the profiles would be: profname session_per_user cpu_per_session cpu_per_call connect_time idle_time logical_reads_per_session logical_reads_per_call 3. A new field would be added to pg_user/pg_shadow: profileid 4. A 'default' profile would be created when a new database is created with no resource limits. CREATE/ALTER user would be modified to allow for the specification of the profile. If no profile is provided, 'default' is assumed. 5. A new CREATE PROFILE/ALTER PROFILE/DROP PROFILE command set would be implemented to add/update/remove the tuples in pg_profiles. And according modification of pg_dump for dump/reload and psql for appropriate \ command. Example: CREATE PROFILE clerk IDLE_TIME 30; ALTER USER john PROFILE clerk; ALTER USER bob PROFILE clerk; or, for an ISP maybe: ALYTER PROFILE default IDLE_TIME 30; It seems like a nice project, particularly since it wouldn't affect anyone that doesn't want to use it. And whenever a new resource limitation issue arrises, such as PL/SQL recursion depth, a new attribute would be added to pg_profile to handle the limitation... Mike Mascari [EMAIL PROTECTED] -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] idle connection timeout ...
Alvaro Herrera wrote: On Sat, Oct 26, 2002 at 11:12:01PM -0400, Bruce Momjian wrote: Tom's idea of doing this as part of the already added per-user/per-db settings seems like a good direction to take. Yes, but how? The current implementation has a setting column in pg_shadow, and another in pg_database. Is the idea to create a separate pg_settings table or something like that? Are you asking how to do per-db-user combination settings, like User A can have only two connections to database B? Seems we should get per-user and per-db settings working first and see if anyone needs combination settings. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] idle connection timeout ...
On Sat, Oct 26, 2002 at 11:58:35PM -0400, Bruce Momjian wrote: Alvaro Herrera wrote: On Sat, Oct 26, 2002 at 11:12:01PM -0400, Bruce Momjian wrote: Tom's idea of doing this as part of the already added per-user/per-db settings seems like a good direction to take. Yes, but how? The current implementation has a setting column in pg_shadow, and another in pg_database. Is the idea to create a separate pg_settings table or something like that? Are you asking how to do per-db-user combination settings, like User A can have only two connections to database B? Seems we should get per-user and per-db settings working first and see if anyone needs combination settings. Well, now that I think about it... the user local to database (those with the dbname appended and all that) idea may very well cover the ground for this. But I'm not actually asking, because I don't need it. -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) Aprender sin pensar es inutil; pensar sin aprender, peligroso (Confucio) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
