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