For what it's worth, for my historical sort benchmarks I got Postgres to build right back to 6.5 using modern tools. I have patches if anyone wants them. Pre-7.3 doesn't actually run because we didn't support 64-bit architectures before Tom did the V1 api (there was a set of Alpha patches floating around but they don't seem sufficient for x86_64). But I suspect if I built it for x86 32-bit that would clear the immediate problem.
I was considering proposing backpatching some minimal patches to get old unsupported branches to at least build with modern tools and run. Just to make it easy for people to test historical behaviour and I suppose pg_dump or other client testing would be a good use case too. I was also going to propose turning off all warnings on these unsupported back branches while I was at it. One other lesson I learned doing this was that it was a pain referring to individual git checkouts because we don't have a tag for point where we branched the new development. So all my git-describes were ending up with things like REL9_2_BETA2-619-gff6c78c or REL9_3_BETA1-925-g6668ad1. You just had to know that REL9_3_BETA1-xxx was probably a revision sometime during PG 9.5 development since BETA1 was probably where we forked development whereas 9.3 probably forked off 9_2_BETA2. (And some were things like REL7_4_RC1-1513-g4525418 instead) I would suggest adding tags for each version on the first development revision so that we could see things like REL9_5_DEV-nnn would mean the nnnth commit on the 9.5 development branch. (What I actually did instead myself was use git describe --tags --contains $i --match 'REL[0-9]_[0-9]_[0-9]' which gave me things like REL9_5_0~1334 which means the 1334th commit *before* REL9_5_0. That was also confusing but at least consistent) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
