This email applies ONLY to the native Windows port of PostgreSQL, not to
any other ports.
Version 8.0 was the first version of PostgreSQL that ran on Windows
natively. As most of you know, the porting work was a large and complex
task that spanned two development cycles and took a great deal of effort
from a number of developers. Despite the success and stability of the
initial port, it was always expected that the first couple of releases
would inevitably have potentially serious bugs in them.
There were a number of such bugs in 8.0, and to a lesser extent, 8.1
some of which required fairly invasive changes to fix, and some
that were simpler, but still remained unfixed in the previous branches
for one reason or another. There were also various invasive changes on
which later bug fixes were dependent.
The core team have discussed this over the last few days, and have
decided that unless one or more developers are willing to put in the
effort to backport these fixes in appropriately non-invasive ways to the
older branches, we will officially cease to support the 8.0 and 8.1
branches on Windows once PostgreSQL 8.3 is released. This means that no
future Windows specific bug fixes will be applied to those branches, and
that no further binary releases will be produced. All other platforms
will remain unaffected.
For reference, a rough list of the issues we found between us is
included below (there are probably more we've forgotten right now). If
you wish to put some effort into the backporting work that is required,
please shout as soon as possible and plan to submit a reasonable amount
of work before the 8.3 deadline.
Unfixed/related issues:
* The stats collector bug which prevented stats being collected
reliably, thus causing all the expected knock on effects (including
near-total failure of autovacuum). The 8.2 fix for this was dependent
on the redesign of the collector to remove the separate stats buffering
process.
* Semaphore issues, fixed by the native implementation in 8.2.
* A bunch of changes for MSVC support (which wasn't finished in time for
8.2, but it still made the Windows port code look a lot different, which
complicates back-patching)
* pg_regress is now a C program, making it usable on Windows
* Some specific patches never applied to 8.1:
2007-03-08 14:27 mha
* src/interfaces/libpq/: bcc32.mak, fe-connect.c, libpqdll.c,win32.mak (REL8_2_STABLE), bcc32.mak, fe-connect.c,
libpqdll.c,win32.mak:Remove unsafe calling of WSAStartup and WSACleanupfrom DllMain. Move the inline cleanup call
aroundso it will becalled in the right order, and be called on errors.Per report from Tokuharu Yuzawa.
2007-02-19 10:05 mha
* src/bin/pg_dump/: pg_backup_archiver.c, pg_backup_archiver.h,pg_backup_custom.c, pg_backup_files.c,
pg_backup_tar.c,pg_dump.h(REL8_2_STABLE), pg_backup_archiver.c,pg_backup_archiver.h, pg_backup_custom.c,
pg_backup_files.c,pg_backup_tar.c,pg_dump.h:Fix pg_dump on win32 to properly dump files larger than 2Gb whenusing
binarydump formats.
2006-07-16 16:17 tgl
* src/: backend/port/win32/signal.c,backend/postmaster/syslogger.c, include/port/win32.h,port/pgsleep.c: In a Windows
backend,don't buildsrc/port/pgsleep.c's version of pg_usleep at all. Instead callthe replacement function in
port/win32/signal.cby that name.Avoids tricky macro-redefinition logic and suppresses a compilerwarning; furthermore it
ensuresthat no one can accidentally usethe non-signal-aware version of pg_usleep in a Windows backend.
--
Dave Page
PostgreSQL Core Team