Обсуждение: Review of VS 2010 support patches

Hi all

I've got through a review of the VS 2010 support patches. Between work 
being busy and some interesting issues getting my 64-bit build 
environment set up it took longer than anticipated. Sorry.

It looks good so far. I haven't had any reply to my email to Brar, so 
there are a few details (like whether x64 builds were tested and how x64 
required libraries were built) I could use, but what I've got done so 
far seems fine.

Details follow.

PATCH FORMATTING
==================

The patch (VS2010v7.patch) seems to mix significant changes with 
whitespace fixes etc. These should be separated for clarity and ease of 
future bisect testing etc. Any "perltidy" run should be done as a 
separate patch, too. This is easy if you are using git, because you can 
just commit each to your local tree then use git format-patch to produce 
nice patches. If you have a local tree with a more complicated history, 
you can use git rebase to tidy up the history before you format-patch.

The patches apply cleanly to git master as of 
21f1e15aafb13ab2430e831a3da7d4d4f525d1ce .

pgflex.pl and pgbison.pl
=====================

pgflex.pl and pgbison.pl are a big improvement over the horrid batch 
files, but are perhaps too little a translation. There's no need for the 
big if(string) then (otherstring) stuff; it can be done much more 
cleanly by storing a simple hash of paths to options and doing a file 
extension substitution to generate the output filenames. The hash only 
needs to be populated for files that get processed with non-default 
options, so for pgflex all you need is:
  %LEX_OPTS = { 'src\backend\parser\scan.c' -> '-CF' };

I can send adjusted versions of pgflex.pl and pgbison.pl that

DOCUMENTATION
===============

I didn't notice any documentation updates to reflect the fact that 
Visual Studio 2010 is now supported. It'd be a good idea to change 
install-windows-full.html (or the source of it, anyway) to mention VS 
2010 support.

TEST RESULTS (x86)
=================

I used a buildenv.pl and config.pl that's known to build under VS 2008 
and pass "vcregress check" with an unpatched copy of git master. I built 
with everything except uuid and tcl enabled; I'll see if I can add them 
later.

The patches applied cleanly, and didn't break VS 2008 builds, which 
continued to work fine after a "clean dist" and "build". "vcregress 
check" still passes.

Builds done with VS 2010 using the patches worked fine, and passed 
"vcregress check" tests.

I should have plcheck and contribcheck results as soon as I've got 
things rebuilt with uuid and tcl.

TEST RESULTS (x64)
=================

I'm still working on 64-bit tests. I've finally found out how to get 
64-bit compilation working under Visual Studio 2008 Express Edition (or, 
rather, Microsoft Windows SDK for Windows 7 and .NET Framework 3.5 SP1) 
so I'll be testing that shortly.

I'm not sure if I'll be able to get 64-bit copies of all the optional 
libraries built, so it may be a more minimal build. It'll include at 
least zlib, plperl and plpython 64-bit support, though. Information from 
Briar about whether he built for 64-bit and if so how he got his 
libraries built would help.

--
Craig Ringer

POST Newspapers
276 Onslow Rd, Shenton Park
Ph: 08 9381 3088     Fax: 08 9388 2258
ABN: 50 008 917 717
http://www.postnewspapers.com.au/

-------- Original Message  --------
Subject: Review of VS 2010 support patches
From: Craig Ringer <craig@postnewspapers.com.au>
To: PG Hackers <pgsql-hackers@postgresql.org>, Brar Piening <brar@gmx.de>
Date: 05.07.2011 14:25

> I haven't had any reply to my email to Brar, so there are a few 
> details (like whether x64 builds were tested and how x64 required 
> libraries were built) I could use, but what I've got done so far seems 
> fine.
I've replied on-list see: 
http://archives.postgresql.org/pgsql-hackers/2011-07/msg00066.php

Seems like i've got fooled by "reply to list" being thunderbird's 
default for mailing lists once more. Sorry for that one.


> The patch (VS2010v7.patch) seems to mix significant changes with 
> whitespace fixes etc.

Current version (VS2010v8.patch) which I've submitted on-list about one 
month ago has fixed this as per Tom Lane's comment.
See: http://archives.postgresql.org/message-id/4DEDB6EE.9060307@gmx.de

> pgflex.pl and pgbison.pl
> =====================
>
> pgflex.pl and pgbison.pl are a big improvement over the horrid batch 
> files, but are perhaps too little a translation. There's no need for 
> the big if(string) then (otherstring) stuff; it can be done much more 
> cleanly by storing a simple hash of paths to options and doing a file 
> extension substitution to generate the output filenames. The hash only 
> needs to be populated for files that get processed with non-default 
> options, so for pgflex all you need is:
>
>   %LEX_OPTS = { 'src\backend\parser\scan.c' -> '-CF' };
>
> I can send adjusted versions of pgflex.pl and pgbison.pl that

I think the approach Andrew Dunstan chose (parsing the Makefiles) is 
even more flexible and future proof. We should probably be using his 
versions.
See: http://archives.postgresql.org/pgsql-hackers/2011-07/msg00140.php 
and http://archives.postgresql.org/pgsql-hackers/2011-07/msg00185.php


>
> DOCUMENTATION
> ===============
>
> I didn't notice any documentation updates to reflect the fact that 
> Visual Studio 2010 is now supported. It'd be a good idea to change 
> install-windows-full.html (or the source of it, anyway) to mention VS 
> 2010 support.

Yep - a clear leftover. I've never written any SGML but I'll try to come 
up with something as soon as as I've got the doc build working on my system.


> I'm not sure if I'll be able to get 64-bit copies of all the optional 
> libraries built, so it may be a more minimal build. It'll include at 
> least zlib, plperl and plpython 64-bit support, though. Information 
> from Briar about whether he built for 64-bit and if so how he got his 
> libraries built would help.

Actually my default builds are 64-bit builds as my PC is Win7 x64 and 
I'm using 64-Bit versions for my PostgreSQL work.
As you noted, the availability of 64-bit libraries was the limiting 
factor for more extensive testing but I haven't run into any Problems 
with my default configuration (nothing but plperl) and some others I've 
tried yet.

Regards,

Brar

On 6/07/2011 2:15 AM, Brar Piening wrote:

> I've replied on-list see:
> http://archives.postgresql.org/pgsql-hackers/2011-07/msg00066.php

Ah, sorry I missed that. I generally can't keep up with -hackers and 
have to rely on being cc'd.

>> The patch (VS2010v7.patch) seems to mix significant changes with
>> whitespace fixes etc.
>
> Current version (VS2010v8.patch) which I've submitted on-list about one
> month ago has fixed this as per Tom Lane's comment.
> See: http://archives.postgresql.org/message-id/4DEDB6EE.9060307@gmx.de

That's what threw me, actually. The patch is named 
"perltidy_before.patch"; I didn't see a separate VS2010v8.patch or link 
to one and was trying to figure out how perltidy_before.patch related to 
VS2010v7.patch .

It turns out that VS2010v8.patch is also attached to the same message.
Not that you'd know it from the ... interesting ... way the web ui 
presents attachments. Sorry I missed it.

> I think the approach Andrew Dunstan chose (parsing the Makefiles) is
> even more flexible and future proof. We should probably be using his
> versions.
> See: http://archives.postgresql.org/pgsql-hackers/2011-07/msg00140.php
> and http://archives.postgresql.org/pgsql-hackers/2011-07/msg00185.php

That makes sense. Do you want to integrate those in a v9 revision along 
wiht a docs patch?

For the docs, it might be worth being more specific about the visual 
studio versions. Instead of:

"PostgreSQL supports the compilers from Visual Studio 2005 and Visual 
Studio 2008. When using the Platform SDK only, or when building for 
64-bit Windows, only Visual Studio 2008 is supported."

I'd suggest writing:

"PostgreSQL supports compilation the compilers shipped with Visual 
Studio 2005, 2008 and 2010 (including Express editions), as well as 
standalone Windows SDK releases 6.0 to 7.1. Only 32-bit PostgreSQL 
builds are supported with SDK versions prior to 6.1 and Visual Studio 
versions prior to 2008."


Additionally, it might be worth expanding on "If you wish to build a 
64-bit version, you must use the 64-bit version of the command, and vice 
versa".

The free SDKs don't install both 32-bit and 64-bit environment start 
menu items; they seem to just pick the local host architecture. My 7.1 
SDK only has a start menu launcher for x64. So: Perhaps it's worth 
mentioning that the "setenv" command can be used from within a Windows 
SDK shell to switch architectures. "setenv /?" produces help. For Visual 
Studio, use \VC\vcvarsall.bat in your Visual Studio installation 
directory. See: 
http://msdn.microsoft.com/en-us/library/x4d2c09s(v=VS.100).aspx

> Actually my default builds are 64-bit builds as my PC is Win7 x64 and
> I'm using 64-Bit versions for my PostgreSQL work.

Ah, OK. Good to know.

I had no problems doing an x64 build using the Windows SDK version 7.1, 
and tests passed fine.

Now I just need to test with Windows SDK 6.0 (if I can even get it to 
install on win7 x64; the installer keeps crashing) as that's the SDK 
shipped with Visual Studio 2005 SP1 .

--
Craig Ringer

POST Newspapers
276 Onslow Rd, Shenton Park
Ph: 08 9381 3088     Fax: 08 9388 2258
ABN: 50 008 917 717
http://www.postnewspapers.com.au/

-------- Original Message  --------
Subject: Re: [HACKERS] Review of VS 2010 support patches
From: Craig Ringer <craig@postnewspapers.com.au>
To: Brar Piening <brar@gmx.de>
Date: 06.07.2011 14:56

> It turns out that VS2010v8.patch is also attached to the same message.
> Not that you'd know it from the ... interesting ... way the web ui 
> presents attachments. Sorry I missed it.

Yes I've also noticed that the web ui has somewhat screwed up the two 
patches attached to my email.

This seems avoidable as one can see in 
http://archives.postgresql.org/pgsql-hackers/2011-07/msg00140.php but I 
don't know how.

[...]

> That makes sense. Do you want to integrate those in a v9 revision 
> along wiht a docs patch?
I certainly could. But as those files are Andrew's work which isn't 
really related to VS2010 build and could as well be commited seperately 
I don't want to take credit for it.
I'll remove my versions from the patch (v9 probably) if those files get 
commited.

[...]


>
> For the docs, it might be worth being more specific about the visual 
> studio versions.

[...]

Thanks for the hints I'll consider then once I'll get started with the docs.

[...]

>
> Now I just need to test with Windows SDK 6.0 (if I can even get it to 
> install on win7 x64; the installer keeps crashing) as that's the SDK 
> shipped with Visual Studio 2005 SP1 .
>
Actually I've also successfully tested an empty (no config.pl) 32-bit 
build using Visual Studio 2005 RTM.

Regards,

Brar

On 07/06/2011 04:41 PM, Brar Piening wrote:
> I certainly could. But as those files are Andrew's work which isn't 
> really related to VS2010 build and could as well be commited 
> seperately I don't want to take credit for it.
> I'll remove my versions from the patch (v9 probably) if those files 
> get commited.
>

I'm just doing some final testing and preparing to commit the new pgflex 
and pgbison.

cheers

andrew

-------- Original Message  --------
Subject: Re: [HACKERS] Review of VS 2010 support patches
From: Andrew Dunstan <andrew@dunslane.net>
To: Brar Piening <brar@gmx.de>
Date: 06.07.2011 22:58

>> I'll remove my versions from the patch (v9 probably) if those files
>> get commited.
>>
>
>
> I'm just doing some final testing and preparing to commit the new
> pgflex and pgbison.


The attached patch includes documentation changes and excludes my
versions of pgbison.pl and pgflex.pl which have been replaced by
Andrews' versions that are already commited.

As before "perltidy_before.patch" has to be applied first and
"VS2010v9.patch" second.

Regards,

Brar

PS: Just in case the web ui concatenates the two patch files again:
perltidy_before.patch has 518 lines with the last line of code being "my
$status = $? >>8;" and VS2010v9.patch has 1608 lines with the last line
of code being "if exist src\backend\win32ver.rc del /q
src\backend\win32ver.rc"

On 7/07/2011 8:26 AM, Brar Piening wrote:
> As before "perltidy_before.patch" has to be applied first and
> "VS2010v9.patch" second.

OK, I've gone through builds with way too many versions of the Windows 
SDK and have test results to report.

The short version: please commit so I never, ever, ever have to do this 
again ;-) . I don't see anything newly broken; the only issues I hit 
were in master as well, and are probably related to local configuration 
issues and/or the sheer profusion of Windows SDK releases I've burdened 
my poor laptop with.

Note that x64 builds reported below are configured for plperl and 
plpython only. Other config.pl options are left at 'undef'.

Test results:
=============

VS 2005
-------

- SDK 6.0 (VS 2005) x86: OK, vcregress check passed

- SDK 6.0 (VS 2005) x64: OK, vcregress check passed

VS 2008
-------

- SDK 6.1 (VS 2008) x86: OK, vcregress check passed

- SDK 6.1 (VS 2008) x64: Failed - vcbuild exited with code 255.                         (Also fails on unpatched git
masterx64)                         Since I'm getting crash report dialogs from                         vcbuild, I'm not
inclinedto blame Pg for this                         issue.
 

- SDK 6.1 (VS 2008) x64 (only plperl enabled): OK, vcregress passed

VS 2010
-------

- SDK 7.0A (VS 2010) x86: OK, vcregress passed
- SDK 7.0A (VS 2010) x64: [Pending, missing x64 tools]

Latest Windows SDK
------------------

- SDK 7.1 x86: OK, vcregress passed
- SDK 7.1 x64: OK (incl. plpython), vcregress passed



Won't test:
===========

- itanium. Does Pg build for itanium as things stand, anyway? Would 
anybody notice or care if it didn't?

Not tested yet, unsure if I'll have time
========================================

- vcregress plcheck, vcregress contrib for each combo

- x64 builds with anything more than plperl and plpython enabled. 
Library availability is a bit of an issue, and building all those 
libraries for x64 is outside what I can currently commit to, especially 
as they all require different build methods and some appear to require 
patches/fixes to build at all.

- ossp-uuid . No binaries available, doesn't have an NMakefile or  vs project, and

Frankly, I suggest leaving these tests for the buildfarm to sort out. I 
don't see any sign of build process issues; they all build fine, and 
it's pretty darn unlikely that build changes would cause them to break 
at runtime. Windows buildfarm coverage looks pretty decent these days.

--
Craig Ringer

POST Newspapers
276 Onslow Rd, Shenton Park
Ph: 08 9381 3088     Fax: 08 9388 2258
ABN: 50 008 917 717
http://www.postnewspapers.com.au/

-------- Original Message  --------
Subject: Re: [HACKERS] Review of VS 2010 support patches
From: Craig Ringer <craig@postnewspapers.com.au>
To: Brar Piening <brar@gmx.de>
Date: 07.07.2011 16:44

>
> Frankly, I suggest leaving these tests for the buildfarm to sort out.
> I don't see any sign of build process issues; they all build fine, and
> it's pretty darn unlikely that build changes would cause them to break
> at runtime. Windows buildfarm coverage looks pretty decent these days.

As I had no Idea whether the buildfarm is even ready to work with VS
2010 I set out and tested it.

I can happily tell you that I have just now completed my first
successful buildfarm run using the attached build-farm.conf

Regards,

Brar

On Thu, Jul 7, 2011 at 02:26, Brar Piening <brar@gmx.de> wrote:
> -------- Original Message  --------
> Subject: Re: [HACKERS] Review of VS 2010 support patches
> From: Andrew Dunstan <andrew@dunslane.net>
> To: Brar Piening <brar@gmx.de>
> Date: 06.07.2011 22:58
>
>>> I'll remove my versions from the patch (v9 probably) if those files get
>>> commited.
>>>
>>
>>
>> I'm just doing some final testing and preparing to commit the new pgflex
>> and pgbison.
>
>
> The attached patch includes documentation changes and excludes my versions
> of pgbison.pl and pgflex.pl which have been replaced by Andrews' versions
> that are already commited.
>
> As before "perltidy_before.patch" has to be applied first and
> "VS2010v9.patch" second.

Something is strange here. Did you run perltidy with the exact
parameters documented in the README file? If so, perltidy seems to be
version- or platform- dependent. I ran it, and got a slightly
different patch. It's not big differences, but the simple fact that
perltidy doesn't always generate the same result is annoying.

Can you run it again, and make sure you get the exact same diff? So
that it wasn't accidentally run off the wrong version or something?

I've attached the differences between your perltidy and my perltidy run.

I'm using (perltidy -v): "This is perltidy, v20090616"

(My plan was to just commit a perltidy run to keep that part out of
the patch for easier handling, but I'd like to figure out this
difference first..)

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

-------- Original Message  --------
Subject: Re: [HACKERS] Review of VS 2010 support patches
From: Magnus Hagander <magnus@hagander.net>
To: Brar Piening <brar@gmx.de>
Date: 08.07.2011 11:38

Sorry for the late response - I've been on a wedding this weekend.
> Something is strange here. Did you run perltidy with the exact
> parameters documented in the README file?
Yes - I usually even copy paste it from the README as "perltidy -b -bl 
-nsfs -naws -l=100 -ole=unix *.pl *.pm" (pasted once more) is hard to 
remember and takes a while to type.
> If so, perltidy seems to be
> version- or platform- dependent. I ran it, and got a slightly
> different patch. It's not big differences, but the simple fact that
> perltidy doesn't always generate the same result is annoying.
>
> Can you run it again, and make sure you get the exact same diff? So
> that it wasn't accidentally run off the wrong version or something?

I just rechecked that applying my two patches vs. applying my two 
patches + running the above perltidy command gives no difference (0 byte 
patch).

> I've attached the differences between your perltidy and my perltidy run.
>
> I'm using (perltidy -v): "This is perltidy, v20090616"

I'm currently using (perl -v): "This is perl 5, version 14, subversion 1 
(v5.14.1) built for MSWin32-x64-multi-thread"
and
(perltidy -v): "This is perltidy, v20101217"

But I've just recently upgraded to the latest Perl version.
The patch has been produced using some 5.12.? ActivePerl and it's 
corresponding perltidy version which (whatever it was) obviously 
produced the same result for me.

http://perltidy.sourceforge.net/ChangeLog.html#2010_12_17 doesn't seem 
to have any Information which would explain our different patches.

Strange...

Regards,

Brar

On Sun, Jul 10, 2011 at 20:46, Brar Piening <brar@gmx.de> wrote:
> Sorry for the late response - I've been on a wedding this weekend.
>>
>> Something is strange here. Did you run perltidy with the exact
>> parameters documented in the README file?
>
> Yes - I usually even copy paste it from the README as "perltidy -b -bl -nsfs
> -naws -l=100 -ole=unix *.pl *.pm" (pasted once more) is hard to remember and
> takes a while to type.


Bleh, that's annoying - that means it behaves different in different versions :S


>> If so, perltidy seems to be
>> version- or platform- dependent. I ran it, and got a slightly
>> different patch. It's not big differences, but the simple fact that
>> perltidy doesn't always generate the same result is annoying.
>>
>> Can you run it again, and make sure you get the exact same diff? So
>> that it wasn't accidentally run off the wrong version or something?
>
> I just rechecked that applying my two patches vs. applying my two patches +
> running the above perltidy command gives no difference (0 byte patch).
>
>> I've attached the differences between your perltidy and my perltidy run.
>>
>> I'm using (perltidy -v): "This is perltidy, v20090616"
>
> I'm currently using (perl -v): "This is perl 5, version 14, subversion 1
> (v5.14.1) built for MSWin32-x64-multi-thread"
> and
> (perltidy -v): "This is perltidy, v20101217"
>
> But I've just recently upgraded to the latest Perl version.
> The patch has been produced using some 5.12.? ActivePerl and it's
> corresponding perltidy version which (whatever it was) obviously produced
> the same result for me.

I'm using 5.10... Not sure if it's the perl version or more likely the
perltidy version that causes the difference, but there's not too much
we can do about that. I'm not sure the differences are big enough that
we actually want to care about it - I think it's easier to just take
changes caused by it out of each commit. We're still getting the large
majority as the same.



So - for now, I have made a perltidy run and committed it, which
should make it slightly easier for reviewing the actual patch :-)

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

On 07/06/2011 08:26 PM, Brar Piening wrote:
> -------- Original Message  --------
> Subject: Re: [HACKERS] Review of VS 2010 support patches
> From: Andrew Dunstan <andrew@dunslane.net>
> To: Brar Piening <brar@gmx.de>
> Date: 06.07.2011 22:58
>
>>> I'll remove my versions from the patch (v9 probably) if those files 
>>> get commited.
>>>
>>
>>
>> I'm just doing some final testing and preparing to commit the new 
>> pgflex and pgbison.
>
>
> The attached patch includes documentation changes and excludes my 
> versions of pgbison.pl and pgflex.pl which have been replaced by 
> Andrews' versions that are already commited.
>
> As before "perltidy_before.patch" has to be applied first and 
> "VS2010v9.patch" second.
>
>

I just started looking at this a bit. One small question: why are we 
using "use base qw(foo);" instead of "use parent qw(foo);" which I 
understand is preferred these days?

cheers

andrew

On Sun, Jul 31, 2011 at 03:25, Andrew Dunstan <andrew@dunslane.net> wrote:
>
>
> On 07/06/2011 08:26 PM, Brar Piening wrote:
>>
>> -------- Original Message  --------
>> Subject: Re: [HACKERS] Review of VS 2010 support patches
>> From: Andrew Dunstan <andrew@dunslane.net>
>> To: Brar Piening <brar@gmx.de>
>> Date: 06.07.2011 22:58
>>
>>>> I'll remove my versions from the patch (v9 probably) if those files get
>>>> commited.
>>>>
>>>
>>>
>>> I'm just doing some final testing and preparing to commit the new pgflex
>>> and pgbison.
>>
>>
>> The attached patch includes documentation changes and excludes my versions
>> of pgbison.pl and pgflex.pl which have been replaced by Andrews' versions
>> that are already commited.
>>
>> As before "perltidy_before.patch" has to be applied first and
>> "VS2010v9.patch" second.
>>
>>
>
> I just started looking at this a bit. One small question: why are we using
> "use base qw(foo);" instead of "use parent qw(foo);" which I understand is
> preferred these days?

I am no perl expert, but I see we are using this already today - in
code written by you in one case ;) I'd assume it was just following
the same standard... If the other way is the way to do it today, I see
no reason not to change it to use that.

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

On Wed, Aug 10, 2011 at 9:03 AM, Magnus Hagander <magnus@hagander.net> wrote:
> I am no perl expert, but I see we are using this already today - in
> code written by you in one case ;) I'd assume it was just following
> the same standard... If the other way is the way to do it today, I see
> no reason not to change it to use that.

This is the first I'm hearing of use parent - has that been around
long enough that we needn't worry about breaking old Perl versions?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On 08/10/2011 09:03 AM, Magnus Hagander wrote:
> On Sun, Jul 31, 2011 at 03:25, Andrew Dunstan<andrew@dunslane.net>  wrote:
>>
>> On 07/06/2011 08:26 PM, Brar Piening wrote:
>>> -------- Original Message  --------
>>> Subject: Re: [HACKERS] Review of VS 2010 support patches
>>> From: Andrew Dunstan<andrew@dunslane.net>
>>> To: Brar Piening<brar@gmx.de>
>>> Date: 06.07.2011 22:58
>>>
>>>>> I'll remove my versions from the patch (v9 probably) if those files get
>>>>> commited.
>>>>>
>>>>
>>>> I'm just doing some final testing and preparing to commit the new pgflex
>>>> and pgbison.
>>>
>>> The attached patch includes documentation changes and excludes my versions
>>> of pgbison.pl and pgflex.pl which have been replaced by Andrews' versions
>>> that are already commited.
>>>
>>> As before "perltidy_before.patch" has to be applied first and
>>> "VS2010v9.patch" second.
>>>
>>>
>> I just started looking at this a bit. One small question: why are we using
>> "use base qw(foo);" instead of "use parent qw(foo);" which I understand is
>> preferred these days?
> I am no perl expert, but I see we are using this already today - in
> code written by you in one case ;) I'd assume it was just following
> the same standard... If the other way is the way to do it today, I see
> no reason not to change it to use that.
>

Umm, where are we using it today?
   [andrew@emma pg_head]$ grep -r -P 'use\s+base' .   ./doc/src/sgml/release-old.sgml:   what lexer you use based on
the  platform you use.   ./doc/src/sgml/charset.sgml:     encoding to use based on the   specified or default locale.
./src/backend/commands/aggregatecmds.c:        * Old style: use   basetype parameter.  This supports aggregates of
./autom4te.cache/output.0:#Required to use basename.   ./autom4te.cache/output.0:# Required to use basename.
./configure:#Required to use basename.   ./configure:# Required to use basename.   [andrew@emma pg_head]$
 


cheers

andrew

On 08/10/2011 09:21 AM, Robert Haas wrote:
> On Wed, Aug 10, 2011 at 9:03 AM, Magnus Hagander<magnus@hagander.net>  wrote:
>> I am no perl expert, but I see we are using this already today - in
>> code written by you in one case ;) I'd assume it was just following
>> the same standard... If the other way is the way to do it today, I see
>> no reason not to change it to use that.
> This is the first I'm hearing of use parent - has that been around
> long enough that we needn't worry about breaking old Perl versions?
>


Good question. Maybe not.

cheers

andrew

On Wed, Aug 10, 2011 at 15:25, Andrew Dunstan <andrew@dunslane.net> wrote:
>
>
> On 08/10/2011 09:03 AM, Magnus Hagander wrote:
>>
>> On Sun, Jul 31, 2011 at 03:25, Andrew Dunstan<andrew@dunslane.net>  wrote:
>>>
>>> On 07/06/2011 08:26 PM, Brar Piening wrote:
>>>>
>>>> -------- Original Message  --------
>>>> Subject: Re: [HACKERS] Review of VS 2010 support patches
>>>> From: Andrew Dunstan<andrew@dunslane.net>
>>>> To: Brar Piening<brar@gmx.de>
>>>> Date: 06.07.2011 22:58
>>>>
>>>>>> I'll remove my versions from the patch (v9 probably) if those files
>>>>>> get
>>>>>> commited.
>>>>>>
>>>>>
>>>>> I'm just doing some final testing and preparing to commit the new
>>>>> pgflex
>>>>> and pgbison.
>>>>
>>>> The attached patch includes documentation changes and excludes my
>>>> versions
>>>> of pgbison.pl and pgflex.pl which have been replaced by Andrews'
>>>> versions
>>>> that are already commited.
>>>>
>>>> As before "perltidy_before.patch" has to be applied first and
>>>> "VS2010v9.patch" second.
>>>>
>>>>
>>> I just started looking at this a bit. One small question: why are we
>>> using
>>> "use base qw(foo);" instead of "use parent qw(foo);" which I understand
>>> is
>>> preferred these days?
>>
>> I am no perl expert, but I see we are using this already today - in
>> code written by you in one case ;) I'd assume it was just following
>> the same standard... If the other way is the way to do it today, I see
>> no reason not to change it to use that.
>>
>
> Umm, where are we using it today?
>
>   [andrew@emma pg_head]$ grep -r -P 'use\s+base' .
>   ./doc/src/sgml/release-old.sgml:   what lexer you use based on the
>   platform you use.
>   ./doc/src/sgml/charset.sgml:     encoding to use based on the
>   specified or default locale.
>   ./src/backend/commands/aggregatecmds.c:         * Old style: use
>   basetype parameter.  This supports aggregates of
>   ./autom4te.cache/output.0:# Required to use basename.
>   ./autom4te.cache/output.0:# Required to use basename.
>   ./configure:# Required to use basename.
>   ./configure:# Required to use basename.
>   [andrew@emma pg_head]$

Meh. I am clearly not back in the game since my vacation. I didn't
realize base was a keyword... Ignore and move on, nothing to see here.


--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

Brar Piening wrote:
>
> The attached patch includes documentation changes and excludes my
> versions of pgbison.pl and pgflex.pl which have been replaced by
> Andrews' versions that are already commited.

Building current head today I noticed that the patch doesn't apply
cleanly anymore.

Attached is a new version.

Regards,

Brar

On 09/28/2011 03:53 PM, Brar Piening wrote:
> Brar Piening wrote:
>>
>> The attached patch includes documentation changes and excludes my 
>> versions of pgbison.pl and pgflex.pl which have been replaced by 
>> Andrews' versions that are already commited.
>
> Building current head today I noticed that the patch doesn't apply 
> cleanly anymore.
>
> Attached is a new version.
>
>


This patch looks OK in principle.

Some minor nitpicks:

Do we really need to create all those VSnnnnProject.pm and 
VSnnnnSolution.pm files? They are all always included anyway. Why not 
just stash all the packages in Solution.pm and Project.pm? Also, instead 
of doing this in Mkvcbuild.pm:
   my $vsVersion = VSObjectFactory::DetermineVisualStudioVersion();   $solution =
VSObjectFactory::CreateSolution($vsVersion,$config);
 

why not just add "use VSObjectFactory;" at the top of the file and 
import these into the current namespace, just as we do for pretty much 
everything else?

There are some stylistic things that aren't the way I usually do things 
(use of named instead of anonymous file handles, use of heredocs instead 
of qq{} style quotes) and that I would prefer done differently, but 
those are more matters of taste than substance. I also generally dislike 
composing XML by non-formal means, as it can be quite error prone and 
often leads to errors in unforeseen corner cases. But in this case we 
certainly don't want to impose an extra requirement on some perl XML 
module, and it would make this code terribly verbose, so we just have to 
hope we get it right :-)

I don't have a VS2010 machine available to test it on unfortunately. 
I'll see what I can do about arranging one, at least temporarily. 
Meanwhile I'll test it on my VS2005 and VS2008 machines to make sure it 
doesn't break anything.

cheers

andrew

Andrew Dunstan wrote:
>
> Some minor nitpicks:
>
> Do we really need to create all those VSnnnnProject.pm and 
> VSnnnnSolution.pm files? They are all always included anyway. Why not 
> just stash all the packages in Solution.pm and Project.pm? 
We certainly don't *need* them.
Having different files separates the tasks of generating different 
target file formats into different source files. In my opinion this 
makes it easier to find the code that is actually generating the files 
that get used in a specific build environment.
While the VSnnnnSolution.pm and VC200nProject.pm files are indeed not 
much more than stubs that could eventually be extended in future (and 
probably never will) VC2010Project.pm contains the whole code for 
generating the new file format which would significantly bloat up the 
code in Project.pm that currently contains the common code for 
generating the old file formats.

Anyhow - this is just my opinion and my intention is to help improving 
the Windows build process and not forcing my design into the project.

> Also, instead of doing this in Mkvcbuild.pm:
>
>    my $vsVersion = VSObjectFactory::DetermineVisualStudioVersion();
>    $solution = VSObjectFactory::CreateSolution($vsVersion, $config);
>
> why not just add "use VSObjectFactory;" at the top of the file and 
> import these into the current namespace, just as we do for pretty much 
> everything else?

Yes - my way (singleton, clean namespace) is probably overengineering in 
this context.

>
> There are some stylistic things that aren't the way I usually do 
> things (use of named instead of anonymous file handles, use of 
> heredocs instead of qq{} style quotes) and that I would prefer done 
> differently, but those are more matters of taste than substance. 
Please go ahead and change it to whatever style you prefer. There is 
certainly more than one way to style it ;-)

> I also generally dislike composing XML by non-formal means, as it can 
> be quite error prone and often leads to errors in unforeseen corner 
> cases. But in this case we certainly don't want to impose an extra 
> requirement on some perl XML module, and it would make this code 
> terribly verbose, so we just have to hope we get it right :-)
I actually had a look into the default ActivePerl docs to find out 
whether there is a better way for generating xml, but as there is no 
XML-generator package in the default distribution I decided not to 
introduce a new dependency.

Thanks for your feedback.

Regards,

Brar

On 11/29/2011 10:01 AM, Andrew Dunstan wrote:
>
>
> I don't have a VS2010 machine available to test it on unfortunately. 
> I'll see what I can do about arranging one, at least temporarily. 
> Meanwhile I'll test it on my VS2005 and VS2008 machines to make sure 
> it doesn't break anything.
>


I can confirm that it does work on my 2005 and 2008 platforms.

cheers

andrew

On 11/29/2011 04:32 PM, Brar Piening wrote:
> Andrew Dunstan wrote:
>>
>> Some minor nitpicks:
>>
>> Do we really need to create all those VSnnnnProject.pm and 
>> VSnnnnSolution.pm files? They are all always included anyway. Why not 
>> just stash all the packages in Solution.pm and Project.pm? 
> We certainly don't *need* them.
> Having different files separates the tasks of generating different 
> target file formats into different source files. In my opinion this 
> makes it easier to find the code that is actually generating the files 
> that get used in a specific build environment.
> While the VSnnnnSolution.pm and VC200nProject.pm files are indeed not 
> much more than stubs that could eventually be extended in future (and 
> probably never will) VC2010Project.pm contains the whole code for 
> generating the new file format which would significantly bloat up the 
> code in Project.pm that currently contains the common code for 
> generating the old file formats.
>
>


Does anyone else have an opinion on this. I want to wrap this up ASAP so 
we can get a VS2010 buildfarm member working.

cheers

andrew

On Thu, Dec 1, 2011 at 01:06, Andrew Dunstan <andrew@dunslane.net> wrote:
>
>
> On 11/29/2011 04:32 PM, Brar Piening wrote:
>>
>> Andrew Dunstan wrote:
>>>
>>> Some minor nitpicks:
>>>
>>> Do we really need to create all those VSnnnnProject.pm and
>>> VSnnnnSolution.pm files? They are all always included anyway. Why not just
>>> stash all the packages in Solution.pm and Project.pm?
>>
>> We certainly don't *need* them.
>> Having different files separates the tasks of generating different target
>> file formats into different source files. In my opinion this makes it easier
>> to find the code that is actually generating the files that get used in a
>> specific build environment.
>> While the VSnnnnSolution.pm and VC200nProject.pm files are indeed not much
>> more than stubs that could eventually be extended in future (and probably
>> never will) VC2010Project.pm contains the whole code for generating the new
>> file format which would significantly bloat up the code in Project.pm that
>> currently contains the common code for generating the old file formats.
>>
>
> Does anyone else have an opinion on this. I want to wrap this up ASAP so we
> can get a VS2010 buildfarm member working.

I guess the most likely one would be me, but not really. My perl-fu is
well below this level, so I will happily +1 whatever you more
experienced perl guys say :-) I don't see a big problem with a couple
of more files - it's not like we're going to support 20 different
versions of VS anyway, once we get to 4 i'm sure the earliest one is
well out of support already and can be removed. But in summary I'd
vote for whatever matches the "general perl pest practices" at this
time.

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

Magnus Hagander wrote:
>   I'd vote for whatever matches the "general perl pest practices" at 
> this time. 

I didn't kow the "perl pest practices" until now but as the PostgreSQL 
community is more into C I think I know what you mean ;-)

On 11/29/2011 04:32 PM, Brar Piening wrote:
> Andrew Dunstan wrote:
>>
>> Some minor nitpicks:
>>
>> Do we really need to create all those VSnnnnProject.pm and 
>> VSnnnnSolution.pm files? They are all always included anyway. Why not 
>> just stash all the packages in Solution.pm and Project.pm? 
> We certainly don't *need* them.
> Having different files separates the tasks of generating different 
> target file formats into different source files. In my opinion this 
> makes it easier to find the code that is actually generating the files 
> that get used in a specific build environment.
> While the VSnnnnSolution.pm and VC200nProject.pm files are indeed not 
> much more than stubs that could eventually be extended in future (and 
> probably never will) VC2010Project.pm contains the whole code for 
> generating the new file format which would significantly bloat up the 
> code in Project.pm that currently contains the common code for 
> generating the old file formats.
>
> Anyhow - this is just my opinion and my intention is to help improving 
> the Windows build process and not forcing my design into the project.
>

Well, I do also dislike the asymmetry of it. Here's what I suggest: for 
the Solution files, we'll just put the object packages in Solution.pm. 
There really doesn't seem like any need for those to have tiny files on 
their own. For the Project files, factor out the 2005/2008 specific 
parts from Project.pm into a new file, and have a new file for the 
equivalent parts of your new VC2010Project.pm. Then we'll add packages 
to Project.pm to create objects just like I'm suggesting above for 
Solution.pm. The result is then more symmetrical and we'll have three 
new files instead of seven (counting VSObjectFactory.pm).

Perhaps, too, this has all got sufficiently  complicated that adding 
some descritpion of what's going on here to README would be in order. I 
suspect some of my fellow committers tend to look at the whole thing and 
scratch their heads a bit, and that means expecting other people to make 
sense if it is probably a bit much ;-)

cheers

andrew

On 12/04/2011 12:44 PM, Andrew Dunstan wrote:
>
>
> On 11/29/2011 04:32 PM, Brar Piening wrote:
>> Andrew Dunstan wrote:
>>>
>>> Some minor nitpicks:
>>>
>>> Do we really need to create all those VSnnnnProject.pm and 
>>> VSnnnnSolution.pm files? They are all always included anyway. Why 
>>> not just stash all the packages in Solution.pm and Project.pm? 
>> We certainly don't *need* them.
>> Having different files separates the tasks of generating different 
>> target file formats into different source files. In my opinion this 
>> makes it easier to find the code that is actually generating the 
>> files that get used in a specific build environment.
>> While the VSnnnnSolution.pm and VC200nProject.pm files are indeed not 
>> much more than stubs that could eventually be extended in future (and 
>> probably never will) VC2010Project.pm contains the whole code for 
>> generating the new file format which would significantly bloat up the 
>> code in Project.pm that currently contains the common code for 
>> generating the old file formats.
>>
>> Anyhow - this is just my opinion and my intention is to help 
>> improving the Windows build process and not forcing my design into 
>> the project.
>>
>
> Well, I do also dislike the asymmetry of it. Here's what I suggest: 
> for the Solution files, we'll just put the object packages in 
> Solution.pm. There really doesn't seem like any need for those to have 
> tiny files on their own. For the Project files, factor out the 
> 2005/2008 specific parts from Project.pm into a new file, and have a 
> new file for the equivalent parts of your new VC2010Project.pm. Then 
> we'll add packages to Project.pm to create objects just like I'm 
> suggesting above for Solution.pm. The result is then more symmetrical 
> and we'll have three new files instead of seven (counting 
> VSObjectFactory.pm).
>
> Perhaps, too, this has all got sufficiently  complicated that adding 
> some descritpion of what's going on here to README would be in order. 
> I suspect some of my fellow committers tend to look at the whole thing 
> and scratch their heads a bit, and that means expecting other people 
> to make sense if it is probably a bit much ;-)
>
>

In the absence of reaction to this I've marked the patch as "waiting on 
author", but if/when I have time I'll work on rearranging things as above.

cheers

andrew

Andrew Dunstan wrote:
>
> In the absence of reaction to this I've marked the patch as "waiting 
> on author", but if/when I have time I'll work on rearranging things as 
> above.

Sorry for my non-reaction.

I'm currently trying to find some time window in my before chrismas 
schedule but it seems like I can't guarantee anything.

Anyhow I'll try to make it happen within "this year".

Regards,

Brar

On 12/10/2011 12:58 PM, Brar Piening wrote:
> I'm currently trying to find some time window in my before chrismas 
> schedule but it seems like I can't guarantee anything.
>
> Anyhow I'll try to make it happen within "this year".

That's fair, and Andrew or something else may get an itch to just plow 
forward and do it themselves.  I'm going to mark this one returned with 
feedback for now.  So long as we get an update from you before the 
January 15th CommitFest, this should still be feasible to slip into 9.2.

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support  www.2ndQuadrant.us

Andrew Dunstan wrote:
> Well, I do also dislike the asymmetry of it. Here's what I suggest:
> for the Solution files, we'll just put the object packages in
> Solution.pm. There really doesn't seem like any need for those to have
> tiny files on their own. For the Project files, factor out the
> 2005/2008 specific parts from Project.pm into a new file, and have a
> new file for the equivalent parts of your new VC2010Project.pm. Then
> we'll add packages to Project.pm to create objects just like I'm
> suggesting above for Solution.pm. The result is then more symmetrical
> and we'll have three new files instead of seven (counting
> VSObjectFactory.pm).
>
> Perhaps, too, this has all got sufficiently  complicated that adding
> some descritpion of what's going on here to README would be in order.
> I suspect some of my fellow committers tend to look at the whole thing
> and scratch their heads a bit, and that means expecting other people
> to make sense if it is probably a bit much ;-)

Attached is an updated patch which includes your suggestions.

I have to admit that it's currently broken (it builds but fails during
regression tests becuse it can't connect) when building with Visual
Studio 2010 or Windows SDK 7.1 because of commit
1a0c76c32fe470142d3663dd84ac960d75a4e8db (Enable compiling with the
mingw-w64 32 bit compiler).

It seems like VS 2010 has a few of the E... constants in
src/include/port/win32.h already defined, but obviously in a way that
breaks postgres.

Because of my missing experience and as I don't have a Mingw64 build
environment I don't feel like I could fix that without breaking anythig
else.

Regards,

Brar

Brar Piening wrote:
> I have to admit that it's currently broken (it builds but fails during 
> regression tests becuse it can't connect) when building with Visual 
> Studio 2010 or Windows SDK 7.1 because of commit 
> 1a0c76c32fe470142d3663dd84ac960d75a4e8db (Enable compiling with the 
> mingw-w64 32 bit compiler).
>
> It seems like VS 2010 has a few of the E... constants in 
> src/include/port/win32.h already defined, but obviously in a way that 
> breaks postgres.
>
> Because of my missing experience and as I don't have a Mingw64 build 
> environment I don't feel like I could fix that without breaking 
> anythig else.

I'd like to add that I'm certainly willing to test suggested fixes or 
patches in my VS 2010 build environment.

Regards,
Brar

On Wed, Dec 28, 2011 at 05:09, Brar Piening <brar@gmx.de> wrote:
> Brar Piening wrote:
>>
>> I have to admit that it's currently broken (it builds but fails during
>> regression tests becuse it can't connect) when building with Visual Studio
>> 2010 or Windows SDK 7.1 because of commit
>> 1a0c76c32fe470142d3663dd84ac960d75a4e8db (Enable compiling with the
>> mingw-w64 32 bit compiler).
>>
>> It seems like VS 2010 has a few of the E... constants in
>> src/include/port/win32.h already defined, but obviously in a way that breaks
>> postgres.
>>
>> Because of my missing experience and as I don't have a Mingw64 build
>> environment I don't feel like I could fix that without breaking anythig
>> else.
>
>
> I'd like to add that I'm certainly willing to test suggested fixes or
> patches in my VS 2010 build environment.


What actual error do you get when trying to connect?

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

On 12/27/2011 11:09 PM, Brar Piening wrote:
> Brar Piening wrote:
>> I have to admit that it's currently broken (it builds but fails 
>> during regression tests becuse it can't connect) when building with 
>> Visual Studio 2010 or Windows SDK 7.1 because of commit 
>> 1a0c76c32fe470142d3663dd84ac960d75a4e8db (Enable compiling with the 
>> mingw-w64 32 bit compiler).
>>
>> It seems like VS 2010 has a few of the E... constants in 
>> src/include/port/win32.h already defined, but obviously in a way that 
>> breaks postgres.
>>
>> Because of my missing experience and as I don't have a Mingw64 build 
>> environment I don't feel like I could fix that without breaking 
>> anythig else.
>
> I'd like to add that I'm certainly willing to test suggested fixes or 
> patches in my VS 2010 build environment.
>
>

Can you narrow down exactly what in that commit broke VS 2010? Are there 
any compiler warnings?

cheers

andrew

On Wed, Dec 28, 2011 at 14:38, Andrew Dunstan <andrew@dunslane.net> wrote:
>
>
> On 12/27/2011 11:09 PM, Brar Piening wrote:
>>
>> Brar Piening wrote:
>>>
>>> I have to admit that it's currently broken (it builds but fails during
>>> regression tests becuse it can't connect) when building with Visual Studio
>>> 2010 or Windows SDK 7.1 because of commit
>>> 1a0c76c32fe470142d3663dd84ac960d75a4e8db (Enable compiling with the
>>> mingw-w64 32 bit compiler).
>>>
>>> It seems like VS 2010 has a few of the E... constants in
>>> src/include/port/win32.h already defined, but obviously in a way that breaks
>>> postgres.
>>>
>>> Because of my missing experience and as I don't have a Mingw64 build
>>> environment I don't feel like I could fix that without breaking anythig
>>> else.
>>
>>
>> I'd like to add that I'm certainly willing to test suggested fixes or
>> patches in my VS 2010 build environment.
>>
>>
>
> Can you narrow down exactly what in that commit broke VS 2010? Are there any
> compiler warnings?

He did post the commit - 1a0c76c32fe470142d3663dd84ac960d75a4e8db.

Not the exact error or warnings, though ;)

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

On 12/28/2011 08:43 AM, Magnus Hagander wrote:
> On Wed, Dec 28, 2011 at 14:38, Andrew Dunstan<andrew@dunslane.net>  wrote:
>>
>> On 12/27/2011 11:09 PM, Brar Piening wrote:
>>> Brar Piening wrote:
>>>> I have to admit that it's currently broken (it builds but fails during
>>>> regression tests becuse it can't connect) when building with Visual Studio
>>>> 2010 or Windows SDK 7.1 because of commit
>>>> 1a0c76c32fe470142d3663dd84ac960d75a4e8db (Enable compiling with the
>>>> mingw-w64 32 bit compiler).
>>>>
>>>> It seems like VS 2010 has a few of the E... constants in
>>>> src/include/port/win32.h already defined, but obviously in a way that breaks
>>>> postgres.
>>>>
>>>> Because of my missing experience and as I don't have a Mingw64 build
>>>> environment I don't feel like I could fix that without breaking anythig
>>>> else.
>>>
>>> I'd like to add that I'm certainly willing to test suggested fixes or
>>> patches in my VS 2010 build environment.
>>>
>>>
>> Can you narrow down exactly what in that commit broke VS 2010? Are there any
>> compiler warnings?
> He did post the commit - 1a0c76c32fe470142d3663dd84ac960d75a4e8db.


I realize that. I'm asking him to narrow it down more.


cheers

andrew

On Wed, Dec 28, 2011 at 15:08, Andrew Dunstan <andrew@dunslane.net> wrote:
>
>
> On 12/28/2011 08:43 AM, Magnus Hagander wrote:
>>
>> On Wed, Dec 28, 2011 at 14:38, Andrew Dunstan<andrew@dunslane.net>  wrote:
>>>
>>>
>>> On 12/27/2011 11:09 PM, Brar Piening wrote:
>>>>
>>>> Brar Piening wrote:
>>>>>
>>>>> I have to admit that it's currently broken (it builds but fails during
>>>>> regression tests becuse it can't connect) when building with Visual
>>>>> Studio
>>>>> 2010 or Windows SDK 7.1 because of commit
>>>>> 1a0c76c32fe470142d3663dd84ac960d75a4e8db (Enable compiling with the
>>>>> mingw-w64 32 bit compiler).
>>>>>
>>>>> It seems like VS 2010 has a few of the E... constants in
>>>>> src/include/port/win32.h already defined, but obviously in a way that
>>>>> breaks
>>>>> postgres.
>>>>>
>>>>> Because of my missing experience and as I don't have a Mingw64 build
>>>>> environment I don't feel like I could fix that without breaking anythig
>>>>> else.
>>>>
>>>>
>>>> I'd like to add that I'm certainly willing to test suggested fixes or
>>>> patches in my VS 2010 build environment.
>>>>
>>>>
>>> Can you narrow down exactly what in that commit broke VS 2010? Are there
>>> any
>>> compiler warnings?
>>
>> He did post the commit - 1a0c76c32fe470142d3663dd84ac960d75a4e8db.
>
>
>
> I realize that. I'm asking him to narrow it down more.

Meh. I can't read. Sorry about that.


--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

Andrew Dunstan wrote:
> Can you narrow down exactly what in that commit broke VS 2010? Are 
> there any compiler warnings?

I was able to nail down the problem.

Running the regression tests (vcregress check) gives the following messages:
<snip>
============== creating temporary installation        ==============
============== initializing database system           ==============
============== starting postmaster                    ==============

pg_regress: postmaster did not respond within 60 seconds
Examine src/test/regress/log/postmaster.log for the reason
</snip>

postmaster.log shows the following messages:
<snip>
LOG:  database system was shut down at 2011-12-28 22:09:46 CET
LOG:  database system is ready to accept connections
LOG:  autovacuum launcher started
LOG:  incomplete startup packet
</snip>
with the line "LOG:  incomplete startup packet" repeated several times 
afterwards.

The problem seems to be related to an invalid socket error constant.
EWOULDBLOCK gets expanded to 140 with commit 
1a0c76c32fe470142d3663dd84ac960d75a4e8db applied whereas it got expanded 
to 10035L before. Adding the following code to src/include/port/win32.h restores the 
former (running) behaviour :
<snip>
#if _MSC_VER >= 1600
#pragma warning(disable:4005)
#define EWOULDBLOCK WSAEWOULDBLOCK
#endif
</snip>

But according to the winsock docs this minimal invasive surgery isn't 
really appropriate (at least for visual c).
http://msdn.microsoft.com/en-us/library/windows/desktop/ms737828(v=vs.85).aspx

It appears that VS 2010 and Windows SDK 7.1 now have an extended errno.h 
that defines quite a few of the E* constants:
<snip>
/* POSIX SUPPLEMENT */
#define EADDRINUSE      100
#define EADDRNOTAVAIL   101
[...]
#define ETXTBSY         139
#define EWOULDBLOCK     140
</snip>

Here we probably run into the conflict that winsock2.h has always been 
warning about:
<snip>
/* * Windows Sockets errors redefined as regular Berkeley error constants. * These are commented out in Windows NT to
avoidconflicts with errno.h. * Use the WSA constants instead. */
 
#if 0
#define EWOULDBLOCK             WSAEWOULDBLOCK
[...]
#define ESTALE                  WSAESTALE
#define EREMOTE                 WSAEREMOTE
#endif
</snip>

A possible solution would be to use something like PGEWOULDBLOCK and 
similiar constants wherever socket errors are used and set them to the 
WSAE* constants on windows and the E* constants on other platforms.

Anyhow, this would be ways beyond the scope of my patch and there will 
probably be a better solution to be suggested from a real C hacker.

Regards,

Brar

Brar Piening wrote:
> Andrew Dunstan wrote:
>> Can you narrow down exactly what in that commit broke VS 2010? Are
>> there any compiler warnings?
>
> I was able to nail down the problem.

In the absence of reaction, to keep my promise, I'm sending the attached
Patch which restores the previous working behaviour for Visual Studio 2011.
Note however that it also restores the previous conflicts with errno.h
which aren't neccessarily a problem, but might be in future.

Regards,

Brar

On 12/31/2011 06:10 PM, Brar Piening wrote:
> Brar Piening wrote:
>> Andrew Dunstan wrote:
>>> Can you narrow down exactly what in that commit broke VS 2010? Are 
>>> there any compiler warnings?
>>
>> I was able to nail down the problem.
>
> In the absence of reaction, to keep my promise, I'm sending the 
> attached Patch which restores the previous working behaviour for 
> Visual Studio 2011.
> Note however that it also restores the previous conflicts with errno.h 
> which aren't neccessarily a problem, but might be in future.
>

Yeah, are we bothered by this?:
   +  * For Microsoft Visual Studio 2010 and above we intentionally redefine   +  * the regular Berkeley error
constantsand set them to the WSA constants.   +  * Note that this will break if those constants are used for anything
else  +  * than Windows Sockets errors.
 



cheers

andrew

<p><br /> On Jan 2, 2012 12:02 AM, "Andrew Dunstan" <<a
href="mailto:andrew@dunslane.net">andrew@dunslane.net</a>>wrote:<br /> ><br /> ><br /> ><br /> > On
12/31/201106:10 PM, Brar Piening wrote:<br /> >><br /> >> Brar Piening wrote:<br /> >>><br />
>>>Andrew Dunstan wrote:<br /> >>>><br /> >>>> Can you narrow down exactly what in
thatcommit broke VS 2010? Are there any compiler warnings?<br /> >>><br /> >>><br /> >>> I
wasable to nail down the problem.<br /> >><br /> >><br /> >> In the absence of reaction, to keep my
promise,I'm sending the attached Patch which restores the previous working behaviour for Visual Studio 2011.<br />
>>Note however that it also restores the previous conflicts with errno.h which aren't neccessarily a problem, but
mightbe in future.<br /> >><br /> ><br /> > Yeah, are we bothered by this?:<br /> ><br /> >   +  *
ForMicrosoft Visual Studio 2010 and above we intentionally redefine<br /> >   +  * the regular Berkeley error
constantsand set them to the WSA constants.<br /> >   +  * Note that this will break if those constants are used for
anythingelse<br /> >   +  * than Windows Sockets errors.<p>If it's exposed to libpq clients, that's perhaps a
problem.If it's just internally and possibly for server extensions I don't think it's a problem - unless it creates an
incompatibilitybetween msvc and mingw, but I don't think it should? <p>/Magnus <br /> 

On 01/02/2012 09:51 AM, Magnus Hagander wrote:
>
>
> On Jan 2, 2012 12:02 AM, "Andrew Dunstan" <andrew@dunslane.net 
> <mailto:andrew@dunslane.net>> wrote:
> >
> >
> >
> > On 12/31/2011 06:10 PM, Brar Piening wrote:
> >>
> >> Brar Piening wrote:
> >>>
> >>> Andrew Dunstan wrote:
> >>>>
> >>>> Can you narrow down exactly what in that commit broke VS 2010? 
> Are there any compiler warnings?
> >>>
> >>>
> >>> I was able to nail down the problem.
> >>
> >>
> >> In the absence of reaction, to keep my promise, I'm sending the 
> attached Patch which restores the previous working behaviour for 
> Visual Studio 2011.
> >> Note however that it also restores the previous conflicts with 
> errno.h which aren't neccessarily a problem, but might be in future.
> >>
> >
> > Yeah, are we bothered by this?:
> >
> >   +  * For Microsoft Visual Studio 2010 and above we intentionally 
> redefine
> >   +  * the regular Berkeley error constants and set them to the WSA 
> constants.
> >   +  * Note that this will break if those constants are used for 
> anything else
> >   +  * than Windows Sockets errors.
>
> If it's exposed to libpq clients, that's perhaps a problem. If it's 
> just internally and possibly for server extensions I don't think it's 
> a problem - unless it creates an incompatibility between msvc and 
> mingw, but I don't think it should?
>
>

Fair enough. Looks like it won't pollute libpq clients. Arguably server 
extensions could be a bit of a risk though.

I'll review the rest.

cheers

andrew

On 12/31/2011 06:10 PM, Brar Piening wrote:
> Brar Piening wrote:
>> Andrew Dunstan wrote:
>>> Can you narrow down exactly what in that commit broke VS 2010? Are 
>>> there any compiler warnings?
>>
>> I was able to nail down the problem.
>
> In the absence of reaction, to keep my promise, I'm sending the 
> attached Patch which restores the previous working behaviour for 
> Visual Studio 2011.
> Note however that it also restores the previous conflicts with errno.h 
> which aren't neccessarily a problem, but might be in future.
>
>

OK, committed with a minor change to remove another compiler warning.

cheers

andrew