Re: [HACKERS] When is 7.0 going Beta? - Mailing list 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@debis.com (Jan Wieck) #