Horton

Thread

  1. Current 6.3 issues

    Bruce Momjian <maillist@candle.pha.pa.us> — 1998-02-22T20:06:51Z

    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

  2. Re: [HACKERS] Current 6.3 issues

    Tatsuo Ishii <t-ishii@sra.co.jp> — 1998-02-23T03:28:48Z

    >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

  3. Re: [HACKERS] Current 6.3 issues

    Vadim B. Mikheev <vadim@sable.krasnoyarsk.su> — 1998-02-23T14:04:55Z

    > 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

  4. Re: [HACKERS] Current 6.3 issues

    Tom Ivar Helbekkmo <tih@hamartun.priv.no> — 1998-02-23T20:47:34Z

    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"

  5. Re: [HACKERS] Current 6.3 issues

    Tatsuo Ishii <t-ishii@sra.co.jp> — 1998-02-24T00:57:10Z

    >> (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

  6. Re: [HACKERS] Current 6.3 issues

    Tom Ivar Helbekkmo <tih@hamartun.priv.no> — 1998-02-24T05:44:28Z

    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"

  7. Re: [HACKERS] Current 6.3 issues

    Michael Meskes <meskes@topsystem.de> — 1998-02-24T10:55:04Z

    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