Re: [HACKERS] When is 7.0 going Beta?

From: wieck(at)debis(dot)com (Jan Wieck)
To: tgl(at)sss(dot)pgh(dot)pa(dot)us (Tom Lane)
Cc: lockhart(at)alumni(dot)caltech(dot)edu, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] When is 7.0 going Beta?
Date: 1999-12-07 17:15:48
Message-ID: m11vODM-0003kGC@orion.SAPserv.Hamburg.dsh.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:

> Foreign keys: Jan has made some commits; features are there but probably
> rather broken. As long as the FK stuff is unlikely to break any *existing*
> functionality (Jan, do you think that's a safe assumption?) it'd be OK
> to leave it in the tree, documented as "work in progress, use at your
> own risk". Getting feedback from users might actually help with the
> debugging here.

Not as safe as you probably want it.

Initially some ppl offered help for FK stuff. The basic's
have been committed for several weeks now, and no contributor
surfaced. So I don't expect any other help now than what I
already got - bug reports. And that's why I concentrated on
the parser/utility area, to get full support into CREATE
TABLE, and the completeness of MATCH FULL. Voila - a few
hours later I got the first bug report.

Now the bad part, the major change I did was the internal
change of the trigger manager to run driven by a deferred
invocation queue. That's the part that could hurt, because
it isn't complete. All trigger events are collected in memory
up to now, and during a huge transaction with millions of
trigger invocations, it could potentially blow away the
backend. Not only RI triggers, ALL trigger events must run
through the queue, and it must remember anything from the
beginning to detect the "triggered data change" violation or
decide what the actual operation really is and which trigger
to invoke finally.

This queue must be able to use a temp file in the case it
grows too big. Since I cannot easily rollback these changes,
it's a show stopper. I knew that from the beginning and
wouldn't have committed that if we hadn't agreed on 7.0 for
the next release. This work is now delayed due to the missed
help, and it must be delayed more to build a multibackend
test driver. Hiroshi's report showed, that especially
referential integrity tests don't make much sense if run by a
single backend serialized.

> At this point I'm sitting on the fence --- I can see the arguments for
> going either way. But I think I might be leaning in favor of a 6.6,
> unless someone points out an issue I missed.

From my point of view, we could start BETA for a 6.6.6 when I
have the temp file buffered queue and the multibackend driver
plus a test suite ready. Even if I don't like it, personally.

Jan

--

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyle Bateman 1999-12-07 17:22:01 Re: [HACKERS] Raising funds for PostgreSQL
Previous Message Peter Eisentraut 1999-12-07 16:35:28 Re: [HACKERS] When is 7.0 going Beta?