Windows support - PostgreSQL 8.0 and 8.1 - Mailing list pgsql-hackers
From | Dave Page |
---|---|
Subject | Windows support - PostgreSQL 8.0 and 8.1 |
Date | |
Msg-id | 4631B9F6.50408@postgresql.org Whole thread Raw |
Responses |
Re: Windows support - PostgreSQL 8.0 and 8.1
|
List | pgsql-hackers |
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
pgsql-hackers by date: