Re: [HACKERS] When is 7.0 going Beta? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] When is 7.0 going Beta?
Date
Msg-id 23829.944588436@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] When is 7.0 going Beta?  (wieck@debis.com (Jan Wieck))
List pgsql-hackers
wieck@debis.com (Jan Wieck) writes:
>     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.

OK, so having the queue file is a must-do before we could release a 6.6.
(BTW, please consider using storage/file/buffile.c for the queue file;
that handles virtual-file access, segmenting of multi-gig files, and
resource cleanup at abort for you.  If you need features buffile hasn't
got, let me know.)

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

Clearly a good thing for testing referential integrity, but is it needed
to verify that old functionality still works?

OTOH, such a testbed would also be nice for stress-testing the table
locking and SI changes, so maybe it is critical for 6.6 anyway.

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

Would 1 Feb be a good target date for you?  How much would doing things
this way distort your development path, compared to what you'd do if
we didn't plan a 6.6 release?
        regards, tom lane


pgsql-hackers by date:

Previous
From: wieck@debis.com (Jan Wieck)
Date:
Subject: Re: [HACKERS] When is 7.0 going Beta?
Next
From: Tom Lane
Date:
Subject: Parallel regress tests (was Re: FOREIGN KEY and shift/reduce)