Re: Win32, PITR, nested transactions, tablespaces

The world rejoiced as gsstark(at)mit(dot)edu (Greg Stark) wrote:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>
>> Greg Stark <gsstark(at)mit(dot)edu> writes:
>> > This is the only place where I see hardly any movement on major
>> > items the whole development cycle, then a rush of radical changes
>> > just before the freeze.
>>
>> [blink] There's been plenty of stuff done all through this
>> development cycle (and previous ones too). Read the CVS logs if
>> you've forgotten.
>
> Sure, but that's parallel to what I'm saying. This is the only place
> I see "Please delay the freeze so I can squeeze this major change in
> just before the release". In other projects I see "Please hurry up
> and release so I can start committing major changes again".
>
> Perhaps it's an artifact of people doing most of their work offline
> and submitting patches, rather than using the CVS tree as their
> development environment. Or perhaps it's an artifact of ~nobody
> using the CVS version of postgres except for testing patches. Or
> perhaps it's a consequence of the freeze period being so long.

I did a compile the other day of the "latest CVS" version on AIX; I
wasn't seriously testing it in general, but was at least pleased to
see it passing regression cleanly.

One of the things that looks interesting is 2 Phase Commit. THAT has
been holding off for nested transactions to get in place, as both
these features twiddle with how transactions work. Regrettably,
integrating it all together is sure to take a while. From what I see
now, I hope nested transactions make it into 7.5 so that 2PC can make
it into 7.6.

> Or perhaps the serious postgres developers are just so good that
> they're justified in being confident applying major changes just
> before a freeze. Experience does seem to justify that somewhat;
> I've been repeatedly impressed at how such drastic changes seem to
> just work with hardly any changes.

I suspect we may need additional regression tests to check the
behaviour of lazy vacuum and ARC, since they are _usually_ supposed to
be pretty invisible to applications; the regular application and
reapplication of the set of regression tests has been pretty effective
at preventing the code from getting too far away from working validly
along the way.

> Fwiw, I do feel that 7.4 is pretty fresh. At least in my case I
> don't plan on upgrading to 7.5 immediately because 7.4 meets all our
> needs. When we upgrade it'll probably be for PITR, but we don't
> really need it yet.

ARC and lazy vacuum look like valuable things for the "transactional"
systems I'm working with. It looks like we sometimes see delays
coming from checkpoints that 7.5 looks like it may moderate. Mind
you, some systems only recently "leapt" to 7.4, so it would be quite
surprising to quickly leap again to 7.5.

PITR may turn out to be a "don't care" item if Slony1 winds up
providing its own approach to PITR. (e.g. - if you write out to
disk the sets of SQL statements that are to be applied to a replica,
then the spooled sets of these statements represent a history of
updates that can be used to do PITR.)
--
"cbbrowne","@","ntlug.org"
http://www.ntlug.org/~cbbrowne/emacs.html
I'm sorry Dave, I can't let you do that.
Why don't you lie down and take a stress pill?