Open 6.3 issues

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

Here is the newest list:

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

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?
Problem with tables >2Gb, add elog()?
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
REVOKE ALL ON pg_user FROM PUBLIC crashes if run many times, cache issue(Jan)

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

#2Andrew Martin
martin@biochemistry.ucl.ac.uk
In reply to: Bruce Momjian (#1)
Re: [HACKERS] Open 6.3 issues

Here is the newest list:

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

Fix isinf.c irix port problem reported by Andrew(Marc)

This is now fixed, but the latest snapshot has introduced 2 new bugs
into installation under Irix and the template/.similar file hasn't
been fixed.

The current situation is detailed in a separate post.

Andrew

----------------------------------------------------------------------------
Dr. Andrew C.R. Martin University College London
EMAIL: (Work) martin@biochem.ucl.ac.uk (Home) andrew@stagleys.demon.co.uk
URL: http://www.biochem.ucl.ac.uk/~martin
Tel: (Work) +44(0)171 419 3890 (Home) +44(0)1372 275775

#3Noname
jwieck@debis.com
In reply to: Bruce Momjian (#1)
Re: [HACKERS] Open 6.3 issues

Here is the newest list:

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

Views on aggregates fail

Uh oh - Aggregates require a group by clause in the select.
This is correctly copied into the query action in the views
pg_rewrite entry. But the rewrite handler doesn't insert it
into the parsetree. Thus a wrong execution plan in built.

I'll try some things, but expect to get into trouble if the
select from the view contains it's own grouping clauses.

Let's see.

REVOKE ALL ON pg_user FROM PUBLIC crashes if run many times, cache issue(Jan)

Done - sent to Marc - not cvs committed yet!

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #

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

variable block size patch(Darren)

Move to the TODO list please...thanks.

#5The Hermit Hacker
scrappy@hub.org
In reply to: Noname (#3)
Re: [HACKERS] Open 6.3 issues

On Mon, 23 Feb 1998, Jan Wieck wrote:

REVOKE ALL ON pg_user FROM PUBLIC crashes if run many times, cache issue(Jan)

Done - sent to Marc - not cvs committed yet!

Is now...

#6Noname
jwieck@debis.com
In reply to: The Hermit Hacker (#5)
Re: [HACKERS] Open 6.3 issues

On Mon, 23 Feb 1998, Jan Wieck wrote:

REVOKE ALL ON pg_user FROM PUBLIC crashes if run many times, cache issue(Jan)

Done - sent to Marc - not cvs committed yet!

Is now...

Arrrg

Please add the line

if (!bootstrap)

above the

InitLocalInvalidateData();

in postinit.c manually. Calling it in bootstrap mode causes
postgres to dump core. With that test everything is fine.

Thanks, Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #

#7Vadim B. Mikheev
vadim@sable.krasnoyarsk.su
In reply to: Noname (#3)
Re: [HACKERS] Open 6.3 issues

Jan Wieck wrote:

Views on aggregates fail

Uh oh - Aggregates require a group by clause in the select.
This is correctly copied into the query action in the views
pg_rewrite entry. But the rewrite handler doesn't insert it
into the parsetree. Thus a wrong execution plan in built.

I'll try some things, but expect to get into trouble if the
select from the view contains it's own grouping clauses.

There is another way of VIEW implementation: put VIEW' query
as subselect into FROM clause. The last feature is not implemented
yet. It's just a thought...

Vadim