Thread: 7.0 status request
Here are the major open issues for 7.0 that I remember: Foreign Keys - JanWAL - VadimFunction args - TomSystem indcxes - Bruce Outer joins and new multi-query parse tree are questionable items for 7.0. Is this currect? -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> Here are the major open issues for 7.0 that I remember:
> Foreign Keys - Jan
> WAL - Vadim
> Function args - Tom
> System indcxes - Bruce
> Outer joins and new multi-query parse tree are questionable items for
> 7.0.
You might include "join syntax", which will be ready even if outer
joins are not.
Also, didn't some folks express concern that indices on system tables
would make the backend more fragile? Did we resolve that issue?
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Here are the major open issues for 7.0 that I remember:
> Foreign Keys - Jan
> WAL - Vadim
> Function args - Tom
> System indcxes - Bruce
> Outer joins and new multi-query parse tree are questionable items for
> 7.0.
I have a bunch of optimizer tweaking that I'd like to finish before 7.0,
but perhaps that doesn't qualify as a major open issue. There's no
single item there that I would rank as "must fix or don't ship"; yet
I feel we need to make some progress in that area.
I think there are also a lot of unresolved questions about interlocking
and updating of the catalog caches and relcache. These might be
must-fix items. IIRC, Hiroshi is pretty concerned about that area...
regards, tom lane
> > Here are the major open issues for 7.0 that I remember: > > Foreign Keys - Jan > > WAL - Vadim > > Function args - Tom > > System indcxes - Bruce > > Outer joins and new multi-query parse tree are questionable items for > > 7.0. > > You might include "join syntax", which will be ready even if outer > joins are not. > > Also, didn't some folks express concern that indices on system tables > would make the backend more fragile? Did we resolve that issue? We have indexes on most system tables and it isn't a problem currently. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian wrote: > > Here are the major open issues for 7.0 that I remember: [snip] > Is this currect? Is large tuple support not open at this time? I know it is one of the things that has been wanted for ages. I know a discussion about it happened not long ago, but no one stepped up to the plate on it. -- Lamar Owen WGCR Internet Radio
Bruce Momjian wrote:
> > > Here are the major open issues for 7.0 that I remember:
> > > Foreign Keys - Jan
> > > WAL - Vadim
> > > Function args - Tom
> > > System indcxes - Bruce
> > > Outer joins and new multi-query parse tree are questionable items for
> > > 7.0.
> >
> > You might include "join syntax", which will be ready even if outer
> > joins are not.
> >
> > Also, didn't some folks express concern that indices on system tables
> > would make the backend more fragile? Did we resolve that issue?
>
> We have indexes on most system tables and it isn't a problem currently.
It is, because a corrupted index on a system table cannot be
corrected by drop/create, as a user defined index could be.
I don't know why and when reindexdb disappeared, but that
script was a last resort for exactly the situation of a
corrupted system index. Let me take a look if this
functionality could easily be recreated.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
On Fri, Nov 19, 1999 at 08:55:14PM +0100, Jan Wieck wrote:
>
> It is, because a corrupted index on a system table cannot be
> corrected by drop/create, as a user defined index could be.
>
> I don't know why and when reindexdb disappeared, but that
> script was a last resort for exactly the situation of a
> corrupted system index. Let me take a look if this
> functionality could easily be recreated.
>
Jan,
I submitted a very small patch to dumpdb that creates SQL that will
reindex the database. It's then trivial to then redirect that output to
pgsql on UNIX. I run into this problem frequently, so I wanted
to automate the process. I never saw a reply to my post on the list,
so I wonder if it made it.
I'm not sure how reindexdb worked, but if it just generated SQL based of
the indexes in the database it would make sense to only have the SQL
generation in one common place instead of having it in dumpdb and reindexdb.
Two branches of nearly identical code would be a pain to maintain.
-brian
--
The world's most ambitious and comprehensive PC game database project.
http://www.mobygames.com
> Bruce Momjian wrote: > > > > Here are the major open issues for 7.0 that I remember: > [snip] > > Is this currect? > > Is large tuple support not open at this time? I know it is one of the > things that has been wanted for ages. I know a discussion about it > happened not long ago, but no one stepped up to the plate on it. No one has claimed it. It may be too hard. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On 19-Nov-99 Bruce Momjian wrote: > Here are the major open issues for 7.0 that I remember: > > Foreign Keys - Jan > WAL - Vadim > Function args - Tom > System indcxes - Bruce > > Outer joins and new multi-query parse tree are questionable items for > 7.0. > > Is this currect? There was talk about purging functions from libpq. Is there any concensus on which functions may be going away? Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null # include <std/disclaimers.h> Have you seenhttp://www.pop4.net? Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
Lamar Owen <lamar.owen@wgcr.org> writes:
> Bruce Momjian wrote:
>> Here are the major open issues for 7.0 that I remember:
> Is large tuple support not open at this time?
I think Bruce was trying to list the work items that are both large
and fairly likely to be done before 7.0. (I suspect his motivation
is to figure out what changes he should allow for while writing his
book...)
No one has spoken up and said "I will work on large tuples for 7.0",
so it's not on his list. It could still happen though.
regards, tom lane
> I submitted a very small patch to dumpdb that creates SQL that will
> reindex the database. It's then trivial to then redirect that output to
> pgsql on UNIX. I run into this problem frequently, so I wanted
> to automate the process. I never saw a reply to my post on the list,
> so I wonder if it made it.
>
> I'm not sure how reindexdb worked, but if it just generated SQL based of
> the indexes in the database it would make sense to only have the SQL
> generation in one common place instead of having it in dumpdb and reindexdb.
> Two branches of nearly identical code would be a pain to maintain.
It's a different approach. And recreating system catalog
indices cannot work through the regular psql interface. So
your pgdump enhancement will never be able to do that.
You need to be in bootstrap processing mode (the one the
system is running in while initdb) to drop or create indices
on the system catalog tables. Therefore the postmaster must
NOT be running and you have a (very limited) interface to the
bootstrapping postgres process. Thus you'll have to talk the
*.bki.source dialect to issue commands.
I already made some tests, but they all corrupted more than
they fixed :-). Seems the semantics of the Postgres 4.2
reindexdb have been hit by changes in index handling since
1994. Not really surprising to me.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
> Lamar Owen <lamar.owen@wgcr.org> writes: > > Bruce Momjian wrote: > >> Here are the major open issues for 7.0 that I remember: > > > Is large tuple support not open at this time? > > I think Bruce was trying to list the work items that are both large > and fairly likely to be done before 7.0. (I suspect his motivation > is to figure out what changes he should allow for while writing his > book...) Actually, the motivation was to just get a heads-up from everyone that we are on track for 7.0. If someone wanted to cancel their offer of adding a feature, that is usually the way we hear about it. That way, we don't find out just before beta that someone has decided to abandon a feature addition. This doesn't mean they will actually complete the addition, but it does mean that at this time they are going to attempt to complete it for 7.0. As we get closer, the dreaded Open Items list appears to marshall forces to get as many bugs fixed/features as possible, though Tom, your presence is making that unnecessary because you seem to fix the bugs as soon as they come up. In the old days, the stuff stayed in my mailbox, and nearing beta, I would comb through for open bug reports, make a list, and try and get as many fixed as possible. BTW, I am writing the book assuming no additions will be made for 7.0. If they happen, I will rewrite. If I put a feature on paper, there is extra pressure to complete it, and I don't want to do that. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> >> Here are the major open issues for 7.0 that I remember:
> I think Bruce was trying to list the work items that are both large
> and fairly likely to be done before 7.0. (I suspect his motivation
> is to figure out what changes he should allow for while writing his
> book...)
Ah, that reminds me...
I will do a "type reunification" for the date/time types, hopefully by
the end of December. I consider this fairly important and have been
holding off for a major release to do it...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
On 1999-11-18, Bruce Momjian mentioned: > Here are the major open issues for 7.0 that I remember: Does anyone ever plan on dropping any columns? I think this is a must-have for the latest and greatest database system. I'm sure an experienced backend hacker can put something together in a few days. If need be we could just use a radical solution similar to cluster where you have to shut down the whole database and rebuild all indices afterwards, but pleeeeease. Or this forgotten? Impossible? A feature? Just wondering . . . -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
On 1999-11-19, Vince Vielhaber mentioned: > There was talk about purging functions from libpq. Is there any concensus > on which functions may be going away? As far as I'm concerned, the printing functions only have a few more weeks to live ;) -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
> -----Original Message----- > From: owner-pgsql-hackers@postgreSQL.org > [mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Tom Lane > Sent: Friday, November 19, 1999 4:03 PM > To: Bruce Momjian > Cc: PostgreSQL-development > Subject: Re: [HACKERS] 7.0 status request > > I think there are also a lot of unresolved questions about interlocking > and updating of the catalog caches and relcache. These might be > must-fix items. IIRC, Hiroshi is pretty concerned about that area... > Unfortunately I don't have a reasonable solution for interlocking yet. First,row level locking for system tuples not only exclusive but also shared will be needed. I couldn't find the way to implement shared row level locking now. Moreover I'm suspicious that this row level locking could be used for parser/planner. Row level locking(at least in current implemen tation) is held till end of transaction. As for cache invalidation(rollback),I may be able to do something. However new save point feature would need some change around it. I don't know how Vadim would change it. Regards. Hiroshi Inoue Inoue@tpf.co.jp
Hiroshi Inoue wrote: > > As for cache invalidation(rollback),I may be able to do something. > However new save point feature would need some change around > it. I don't know how Vadim would change it. I have no plans to implement it for 7.0... Vadim
> -----Original Message----- > From: root@sunpine.krs.ru [mailto:root@sunpine.krs.ru]On Behalf Of Vadim > Mikheev > Sent: Tuesday, November 23, 1999 11:50 AM > To: Hiroshi Inoue > Cc: Tom Lane; Bruce Momjian; PostgreSQL-development > Subject: Re: [HACKERS] 7.0 status request > > > Hiroshi Inoue wrote: > > > > As for cache invalidation(rollback),I may be able to do something. > > However new save point feature would need some change around > > it. I don't know how Vadim would change it. > > I have no plans to implement it for 7.0... > Doesn't ROLLBACK to a save point rollback catalog cache ? Regards. Hiroshi Inoue Inoue@tpf.co.jp
Hiroshi Inoue wrote: > > > > As for cache invalidation(rollback),I may be able to do something. > > > However new save point feature would need some change around > > > it. I don't know how Vadim would change it. > > > > I have no plans to implement it for 7.0... > > > > Doesn't ROLLBACK to a save point rollback catalog cache ? There will be no savepoints in 7.0... But I'm going to rollback all changes made by xaction on abort... Vadim
> > Hiroshi Inoue wrote: > > > > > > As for cache invalidation(rollback),I may be able to do something. > > > However new save point feature would need some change around > > > it. I don't know how Vadim would change it. > > > > I have no plans to implement it for 7.0... > > > > Doesn't ROLLBACK to a save point rollback catalog cache ? I thought we flush cache on abort, no? -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> -----Original Message----- > From: Bruce Momjian [mailto:pgman@candle.pha.pa.us] > Sent: Tuesday, November 23, 1999 12:38 PM > To: Hiroshi Inoue > Cc: Vadim Mikheev; Tom Lane; PostgreSQL-development > Subject: Re: [HACKERS] 7.0 status request > > > > > Hiroshi Inoue wrote: > > > > > > > > As for cache invalidation(rollback),I may be able to do something. > > > > However new save point feature would need some change around > > > > it. I don't know how Vadim would change it. > > > > > > I have no plans to implement it for 7.0... > > > > > > > Doesn't ROLLBACK to a save point rollback catalog cache ? > > I thought we flush cache on abort, no? > Sorry,I don't remember well now. But at least catalog cache is not rollbacked for the transaction itself in case of abort. Regards. Hiroshi Inoue Inoue@tpf.co.jp