Current 6.3 issues

Started by Bruce Momjianalmost 28 years ago16 messages
#1Bruce Momjian
maillist@candle.pha.pa.us

With Vadim's change, here it is:

---------------------------------------------------------------------------

ORDER BY NULLs problem?
test new view permission code, install new pg_user view for use with \d
max tuple size patch(Darren)
Self-join optimizer performance problem
Get interfaces fixed for new protocol
Profiling improvements?
Do we have a problem with GROUP BY without ORDER BY?
Problem with tables >2Gb
Do we want to add timestamps to elog messages?
ScanKeyData missing initializations
Alpha/64-bit issues, mkoidname() problem
'Can not write block blind' error on createdb and regression collision(Vadim)
Views on aggregates fail
large objects memory exhaustion
Commit sgml document sources(Thomas)
Commit html documents(Thomas)
Commit postscript documents(Thomas)
Fix isinf.c irix port problem reported by Andrew(Marc)
Check select_views regression test
Test ecpg new struct features(Michael)
Test big-endian/little-endian operation(Tatsuo?)?
REVOKE ALL ON pg_user FROM PUBLIC crashes if run many times

--
Bruce Momjian
maillist@candle.pha.pa.us

#2Noname
t-ishii@sra.co.jp
In reply to: Bruce Momjian (#1)
Re: [HACKERS] Current 6.3 issues

Test big-endian/little-endian operation(Tatsuo?)?

I have tested following platforms: Solairs2.6/Sparc, FreeBSD 2.2.1,
Linux/x86, mklinux/ppc. For the testing, I used authentication method
"trust." Testing tool was psql and the tested command was "\dT." I
have comfirmed any combination of above servers/clients works fine.

BTW I have found some problems with Feb 20 snapshot. Could you add
followings to 6.3 issues?

1. SunOS 4.1.4:

(1) in include/config.h:

#ifndef HAVE_INET_ATON
# ifdef HAVE_ARPA_INET_H
# ifdef HAVE_NETINET_IN_H
# include <sys/types.h> <----- necessary
# include <netinet/in.h>
# endif
# include <arpa/inet.h>
# endif

(2) 6.3 doesn't use -Dsunos4 anymore. However we have such codes as:

#if defined(sunos4)
#define memmove(d, s, l) bcopy(s, d, l)
#include <unistd.h>
#endif

this leads to compiling errors in various places. Should we use
#if defined(sparc) && !defined(__svr4)
instead?

2. Solaris 2.6:

Seems almost ok except a minor error in ecpg:

gmake[3]: Entering directory `/export/home/local/src/pgsql/pgsql/src/interfaces/ecpg/preproc'
install -c -m 755 ecpg /usr/local/pgsql/bin
gmake[3]: install: Command not found
gmake[3]: *** [install] Error 127

3. mklinux/ppc:
With Bruce's patches now regression tests are ok. Thanks Bruce!

However ecpg seems to have small problem:

make[3]: Entering directory `/usr/local/src/pgsql/6.3/pgsql/src/interfaces/ecpg/preproc'
/usr/bin/bison -y -d preproc.y
"preproc.y", line 235: type redeclaration for S_SIGNED
make[3]: *** [y.tab.c] Error 1

3. Linux/x86:

configure doesn't use linux-elf for the default template even it is an ELF
system. (I have tested on RedHat4.0)

changing line 105 in configure.in as follows would solve the problem.

GUESS=`grep "^$host_no_ver=" template/.similar 2>/dev/null`
--
Tatsuo Ishii
t-ishii@sra.co.jp

#3Noname
darrenk@insightdist.com
In reply to: Noname (#2)
Re: [HACKERS] Current 6.3 issues

max tuple size patch(Darren)

Can move this to the TODO list. I'd like to get the
variable block size stuff done first, then this would
make much more sense.

darrenk

#4Vadim B. Mikheev
vadim@sable.krasnoyarsk.su
In reply to: Bruce Momjian (#1)
Re: [HACKERS] Current 6.3 issues

Check select_views regression test

Second query is replaced -> there shouldn't be differences any more...

'Can not write block blind' error on createdb and regression collision(Vadim)

New bug was introduced in mdblindwrt(): backend tried to use current
database path when writing data for another data base => path was invalid
=> elog(ERROR). I fixed this: now backend uses GetRawDatabaseInfo()
to get real path for given data base, BUT I don't like this way:
GetRawDatabaseInfo() reads pg_database to get path and this is
really bad for performance!

Keeping in mind implementation of TABLESPACEs in _near_ future
we have to either use symlinks to give backend simple and fast way
to constract full path to a relation or store full path in
buffer header. Shared memory is critical resource but nevertheless
I prefer the second way.

Now about hanging another backends after 'blind' error. This is
very old bug in buffer manager: before doing blind write backend locks
buffer for IO using local spinlock of this buffer, but elog(ERROR)
doesn't releases spinlocks of this type! I tried to fix this too
but decided that there is not enough time to do this now: there are
another "bad places" in bufmgr. Re-visiting of bufmgr was in my
plans after 6.0, but ... hope to do this for 6.4.

Vadim

#5Tom I Helbekkmo
tih@Hamartun.Priv.NO
In reply to: Noname (#2)
Re: [HACKERS] Current 6.3 issues

On Mon, Feb 23, 1998 at 12:28:48PM +0900, t-ishii@sra.co.jp wrote:

(2) 6.3 doesn't use -Dsunos4 anymore. However we have such codes as:

#if defined(sunos4)
#define memmove(d, s, l) bcopy(s, d, l)
#include <unistd.h>
#endif

this leads to compiling errors in various places. Should we use
#if defined(sparc) && !defined(__svr4)
instead?

The above test does not necessarily mean that the system runs SunOS 4!
It would be true on the machine I'm sending this from as well, an SS2
running NetBSD/sparc...

-tih
--
Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier"

#6Noname
t-ishii@sra.co.jp
In reply to: Tom I Helbekkmo (#5)
Re: [HACKERS] Current 6.3 issues

(2) 6.3 doesn't use -Dsunos4 anymore. However we have such codes as:

#if defined(sunos4)
#define memmove(d, s, l) bcopy(s, d, l)
#include <unistd.h>
#endif

this leads to compiling errors in various places. Should we use
#if defined(sparc) && !defined(__svr4)
instead?

The above test does not necessarily mean that the system runs SunOS 4!
It would be true on the machine I'm sending this from as well, an SS2
running NetBSD/sparc...

Good point. What are predefined #define directives for NetBSD/sparc?
For SunOS we have -Dsparc -Dsun -Dunix -D__GCC_NEW_VARARGS__ ...
--
Tatsuo Ishii
t-ishii@sra.co.jp

#7Tom I Helbekkmo
tih@Hamartun.Priv.NO
In reply to: Noname (#6)
Re: [HACKERS] Current 6.3 issues

On Tue, Feb 24, 1998 at 09:57:10AM +0900, t-ishii@sra.co.jp wrote:

Good point. What are predefined #define directives for NetBSD/sparc?
For SunOS we have -Dsparc -Dsun -Dunix -D__GCC_NEW_VARARGS__ ...

barsoom% tools/ccsym
__GNUC__=2
__GNUC_MINOR__=7
unix
sparc
__NetBSD__
__KPRINTF_ATTRIBUTE__
__unix__
__sparc__
__NetBSD__
__KPRINTF_ATTRIBUTE__
__unix
__sparc
system=unix
system=NetBSD
cpu=sparc
machine=sparc

-tih
--
Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier"

#8Michael Meskes
meskes@topsystem.de
In reply to: Noname (#2)
Re: [HACKERS] Current 6.3 issues

t-ishii@sra.co.jp writes:

2. Solaris 2.6:

Seems almost ok except a minor error in ecpg:

gmake[3]: Entering directory `/export/home/local/src/pgsql/pgsql/src/interfaces/ecpg/preproc'
install -c -m 755 ecpg /usr/local/pgsql/bin
gmake[3]: install: Command not found
gmake[3]: *** [install] Error 127

3. mklinux/ppc:
With Bruce's patches now regression tests are ok. Thanks Bruce!

However ecpg seems to have small problem:

make[3]: Entering directory `/usr/local/src/pgsql/6.3/pgsql/src/interfaces/ecpg/preproc'
/usr/bin/bison -y -d preproc.y
"preproc.y", line 235: type redeclaration for S_SIGNED
make[3]: *** [y.tab.c] Error 1

Both will be solved with my next patch. Thanks.

Michael

--
Dr. Michael Meskes, Project-Manager | topsystem Systemhaus GmbH
meskes@topsystem.de | Europark A2, Adenauerstr. 20
meskes@debian.org | 52146 Wuerselen
Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44
Use Debian GNU/Linux! | Fax: (+49) 2405/4670-10

#9Noname
t-ishii@sra.co.jp
In reply to: Michael Meskes (#8)
Re: [HACKERS] Current 6.3 issues

I tested Feb 24 snapshot on SunOS and encountered a problem. any
suggestion?

flex -t pgc.l > pgc.c
gcc -I../../../include -I../include -Wall -DMAJOR_VERSION=1 -DMINOR_VERSION=0 -DPATCHLEVEL=0 -c pgc.c -o pgc.o
In file included from pgc.l:6:
extern.h:14: warning: parameter names (without types) in function declaration
extern.h:14: parse error before `size_t'
pgc.l: In function `yylex':
pgc.l:49: warning: implicit declaration of function `fprintf'
pgc.l:144: warning: implicit declaration of function `fwrite'
pgc.l:108: warning: label `find_rule' defined but not used
pgc.l: In function `yy_get_next_buffer':
pgc.l:386: warning: implicit declaration of function `_filbuf'
pgc.l:387: warning: implicit declaration of function `fread'
pgc.l: At top level:
pgc.l:1005: warning: `yy_flex_realloc' defined but not used
pgc.l:488: warning: `yyunput' defined but not used
gmake[3]: *** [pgc.o] Error 1
gmake[3]: Leaving directory `/auto/srafsb/export5/prj/psarch/src/6.3/pgsql/src/interfaces/ecpg/preproc'
gmake[2]: *** [all] Error 2
gmake[2]: Leaving directory `/auto/srafsb/export5/prj/psarch/src/6.3/pgsql/src/interfaces/ecpg'
gmake[1]: *** [all] Error 2
gmake[1]: Leaving directory `/auto/srafsb/export5/prj/psarch/src/6.3/pgsql/src/interfaces'
gmake: *** [all] Error 2

#10Michael Meskes
meskes@topsystem.de
In reply to: Noname (#9)
Re: [HACKERS] Current 6.3 issues

t-ishii@sra.co.jp writes:

Does it help to add #include <sys/types.h> to pgc.l? I'm not sure which
file I should include to be correct.

Yes.

Is already in CVS.

BTW, line 32 of preproc/main.c has:

char c,

'char c' should be 'int c' I think. Otherwise

while ((c = getopt(argc, argv, "vdo:")) != EOF)

will not work on some platforms.

Thanks. Changed in my source tree. Will be submitted later.

Another problem is SunOS does not have getopt(). Possible solutions
might be:

a. steal getopt(3) source from FreeBSD
b. rewrite main.c so that it does not use getopt().

I would prefer (a) since it would be easier:-) How do you think?

Ehem, how do we solve this in the backend? It does use getopt, too.

Michael

--
Dr. Michael Meskes, Project-Manager | topsystem Systemhaus GmbH
meskes@topsystem.de | Europark A2, Adenauerstr. 20
meskes@debian.org | 52146 Wuerselen
Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44
Use Debian GNU/Linux! | Fax: (+49) 2405/4670-10

#11Noname
t-ishii@sra.co.jp
In reply to: Michael Meskes (#10)
Re: [HACKERS] Current 6.3 issues

At 11:27 AM 98.2.27 +0100, Michael Meskes wrote:

Another problem is SunOS does not have getopt(). Possible solutions
might be:

a. steal getopt(3) source from FreeBSD
b. rewrite main.c so that it does not use getopt().

I would prefer (a) since it would be easier:-) How do you think?

Ehem, how do we solve this in the backend? It does use getopt, too.

Sorry, I was wrong. Maybe I saw a dream:-)
The truth is SunOS does *have* getopt() but does not have getopt.h.
So we need to declare followings somewhere in ecpg.c.

extern char *optarg;
extern int optind;
---
Tatsuo Ishii
t-ishii@sra.co.jp

#12Meskes, Michael
meskes@topsystem.de
In reply to: Noname (#11)
RE: [HACKERS] Current 6.3 issues

But this isn't declared in postmaster.c either. ecpg.c does include
unistd.h if getopt.h does not exist and I think unistd.h is the one that
puts the getopt stuff into postmaster.

Michael

--
Dr. Michael Meskes, Project-Manager | topsystem Systemhaus GmbH
meskes@topsystem.de | Europark A2, Adenauerstr. 20
meskes@debian.org | 52146 Wuerselen
Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44
Use Debian GNU/Linux! | Fax: (+49) 2405/4670-10

Show quoted text

-----Original Message-----
From: t-ishii@sra.co.jp [SMTP:t-ishii@sra.co.jp]
Sent: Friday, February 27, 1998 2:30 PM
To: Michael Meskes
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Current 6.3 issues

Sorry, I was wrong. Maybe I saw a dream:-)
The truth is SunOS does *have* getopt() but does not have getopt.h.
So we need to declare followings somewhere in ecpg.c.

extern char *optarg;
extern int optind;
---
Tatsuo Ishii
t-ishii@sra.co.jp

#13Noname
t-ishii@sra.co.jp
In reply to: Meskes, Michael (#12)
RE: [HACKERS] Current 6.3 issues

At 2:52 PM 98.2.27 +0100, Meskes, Michael wrote:

But this isn't declared in postmaster.c either. ecpg.c does include
unistd.h if getopt.h does not exist and I think unistd.h is the one that
puts the getopt stuff into postmaster.

I see declarations of optarg and optind in backend/postmaster/postmaster.c
around line 216 in Feb 28 snapshot.
---
Tatsuo Ishii
t-ishii@sra.co.jp

#14Michael Meskes
meskes@topsystem.de
In reply to: Noname (#13)
Re: [HACKERS] Current 6.3 issues

Yes, you're right. This should be changed in ecpg.c, too. Could you please
submit a patch for a version that works for you?

Michael

--
Dr. Michael Meskes, Project-Manager | topsystem Systemhaus GmbH
meskes@topsystem.de | Europark A2, Adenauerstr. 20
meskes@debian.org | 52146 Wuerselen
Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44
Use Debian GNU/Linux! | Fax: (+49) 2405/4670-10

#15Noname
t-ishii@sra.co.jp
In reply to: Michael Meskes (#14)
Re: [HACKERS] Current 6.3 issues

Yes, you're right. This should be changed in ecpg.c, too. Could you please
submit a patch for a version that works for you?

Sure. I will submit patches the day after tomorrow (sorry, I don't have
time for that now).
--
Tatsuo Ishii
t-ishii@sra.co.jp

#16Noname
t-ishii@sra.co.jp
In reply to: Noname (#15)
Re: [HACKERS] Current 6.3 issues

Yes, you're right. This should be changed in ecpg.c, too. Could you please
submit a patch for a version that works for you?

Here it is.
--
Tatsuo Ishii
t-ishii@sra.co.jp
--------------------------- cut here ---------------------------
*** ecpg.c.orig	Fri Feb 27 21:59:06 1998
--- ecpg.c	Thu Mar  5 10:36:10 1998
***************
*** 9,14 ****
--- 9,16 ----
  #include <getopt.h>
  #else
  #include <unistd.h>
+ extern int optind;
+ extern char *optarg;
  #endif
  #include <stdlib.h>
  #if defined(HAVE_STRING_H)