Thread: Windows support - PostgreSQL 8.0 and 8.1

Windows support - PostgreSQL 8.0 and 8.1

From
Dave Page
Date:
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


Re: Windows support - PostgreSQL 8.0 and 8.1

From
Andrew Dunstan
Date:

Dave Page wrote:
>
> * 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.
>
>
>   
I think these two justify declaring the Windows port at EOL prior to 
8.2. The others probably not so much. (Who cares if pg_regress is not a 
C program? Who besides developers uses it?)

I hope this will be a one-off exercise, though. In general we should 
declare releases to be at EOL, not ports.

cheers

andrew


Re: Windows support - PostgreSQL 8.0 and 8.1

From
Dave Page
Date:
Andrew Dunstan wrote:
> 
> 
> Dave Page wrote:
>>
>> * 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.
>>
>>
>>   
> I think these two justify declaring the Windows port at EOL prior to
> 8.2. The others probably not so much. (Who cares if pg_regress is not a
> C program? Who besides developers uses it?)

Yeah, a couple of those items were ones that might make backporting
fixes more difficult rather than issues in their own right. That one's
unlikely to be an issue though, I agree.

> I hope this will be a one-off exercise, though. In general we should
> declare releases to be at EOL, not ports.

Yes, that is absolutely the intention.

Regards, Dave


Re: Windows support - PostgreSQL 8.0 and 8.1

From
Tom Lane
Date:
Andrew Dunstan <andrew@dunslane.net> writes:
> I think these two justify declaring the Windows port at EOL prior to 
> 8.2. The others probably not so much. (Who cares if pg_regress is not a 
> C program? Who besides developers uses it?)

The reason to care about it is that the lack of it guarantees the port
will be poorly tested.

> I hope this will be a one-off exercise, though.

Certainly.  We knew going into it that the Windows port would have
teething pains, and so it did.  The 8.0 release was effectively a beta
as far as native Windows was concerned (and was stated to be such).
Dropping 8.1 is a bit more debatable ... but ultimately it comes down
to who is willing to do back-porting effort for Windows-specific bug
fixes, given that the code base has changed so much.  The core team have
agreed that *we* are not going to do that.  If someone else wants to
step up, they're welcome to do so.
        regards, tom lane