FAQ
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/

Search Discussions

  • Brar Piening at Jul 5, 2011 at 6:17 pm

    -------- 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
  • Craig Ringer at Jul 6, 2011 at 12:56 pm

    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/
  • Brar Piening at Jul 6, 2011 at 8:41 pm

    -------- 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
  • Andrew Dunstan at Jul 6, 2011 at 8:58 pm

    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
  • Brar Piening at Jul 7, 2011 at 12:26 am

    -------- 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"
  • Craig Ringer at Jul 7, 2011 at 2:44 pm

    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 master x64)
    Since I'm getting crash report dialogs from
    vcbuild, I'm not inclined to 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/
  • Brar Piening at Jul 7, 2011 at 10:36 pm

    -------- 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
  • Magnus Hagander at Jul 8, 2011 at 9:38 am

    On Thu, Jul 7, 2011 at 02:26, 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.
    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/
  • Brar Piening at Jul 10, 2011 at 7:46 pm

    -------- 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
  • Magnus Hagander at Jul 12, 2011 at 2:29 pm

    On Sun, Jul 10, 2011 at 20:46, Brar Piening 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/
  • Andrew Dunstan at Jul 31, 2011 at 1:26 am

    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
  • Magnus Hagander at Aug 10, 2011 at 1:03 pm

    On Sun, Jul 31, 2011 at 03:25, Andrew Dunstan 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/
  • Robert Haas at Aug 10, 2011 at 1:21 pm

    On Wed, Aug 10, 2011 at 9:03 AM, Magnus Hagander 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
  • Andrew Dunstan at Aug 10, 2011 at 1:26 pm

    On 08/10/2011 09:21 AM, Robert Haas wrote:
    On Wed, Aug 10, 2011 at 9:03 AM, Magnus Haganderwrote:
    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
  • Andrew Dunstan at Aug 10, 2011 at 1:25 pm

    On 08/10/2011 09:03 AM, Magnus Hagander wrote:
    On Sun, Jul 31, 2011 at 03:25, Andrew Dunstanwrote:
    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
  • Magnus Hagander at Aug 10, 2011 at 1:28 pm

    On Wed, Aug 10, 2011 at 15:25, Andrew Dunstan 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 at Sep 28, 2011 at 7:53 pm

    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
  • Andrew Dunstan at Nov 29, 2011 at 3:02 pm

    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
  • Brar Piening at Nov 29, 2011 at 9:32 pm

    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
  • Andrew Dunstan at Dec 1, 2011 at 12:07 am

    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
  • Magnus Hagander at Dec 1, 2011 at 7:50 am

    On Thu, Dec 1, 2011 at 01:06, 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.
    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/
  • Brar Piening at Dec 3, 2011 at 1:00 pm

    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 ;-)
  • Andrew Dunstan at Dec 4, 2011 at 5:45 pm

    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
  • Andrew Dunstan at Dec 9, 2011 at 8:49 pm

    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
  • Brar Piening at Dec 10, 2011 at 5:58 pm

    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
  • Greg Smith at Dec 10, 2011 at 6:11 pm

    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
  • Brar Piening at Dec 27, 2011 at 12:54 am

    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 at Dec 28, 2011 at 4:09 am

    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
  • Magnus Hagander at Dec 28, 2011 at 6:56 am

    On Wed, Dec 28, 2011 at 05:09, 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.

    What actual error do you get when trying to connect?

    --
     Magnus Hagander
     Me: http://www.hagander.net/
     Work: http://www.redpill-linpro.com/
  • Andrew Dunstan at Dec 28, 2011 at 1:39 pm

    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
  • Magnus Hagander at Dec 28, 2011 at 1:43 pm

    On Wed, Dec 28, 2011 at 14:38, Andrew Dunstan 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/
  • Andrew Dunstan at Dec 28, 2011 at 2:08 pm

    On 12/28/2011 08:43 AM, Magnus Hagander wrote:
    On Wed, Dec 28, 2011 at 14:38, Andrew Dunstanwrote:
    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
  • Magnus Hagander at Dec 28, 2011 at 2:11 pm

    On Wed, Dec 28, 2011 at 15:08, Andrew Dunstan 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/
  • Brar Piening at Dec 28, 2011 at 10:44 pm

    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 avoid conflicts 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 at Dec 31, 2011 at 11:10 pm

    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
  • Andrew Dunstan at Jan 1, 2012 at 11:02 pm

    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.



    cheers

    andrew
  • Magnus Hagander at Jan 2, 2012 at 2:51 pm

    On Jan 2, 2012 12:02 AM, "Andrew Dunstan" 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?

    /Magnus
  • Andrew Dunstan at Jan 2, 2012 at 5:18 pm

    On 01/02/2012 09:51 AM, Magnus Hagander wrote:
    On Jan 2, 2012 12:02 AM, "Andrew Dunstan" 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
  • Andrew Dunstan at Jan 3, 2012 at 1:47 pm

    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
  • Andrew Dunstan at Nov 30, 2011 at 4:10 pm

    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedJul 5, '11 at 12:25p
activeJan 3, '12 at 1:47p
posts41
users7
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2022 Grokbase