From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | wieck(at)debis(dot)com (Jan Wieck) |
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:40:36 |
Message-ID: | 23829.944588436@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
wieck(at)debis(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 1999-12-07 17:52:54 | Parallel regress tests (was Re: FOREIGN KEY and shift/reduce) |
Previous Message | Kyle Bateman | 1999-12-07 17:22:01 | Re: [HACKERS] Raising funds for PostgreSQL |