Strange Windows problem, lock_timeout test request

On 01/18/2013 05:43 PM, Boszormenyi Zoltan wrote:

Hi,

using the MinGW cross-compiled PostgreSQL binaries from Fedora 18,
I get the following error for both 32 and 64-bit compiled executables.
listen_addresses = '*' and "trust" authentication was set for both.
The firewall was disabled for the tests and the server logs
"incomplete startup packet".
The 64-bit version was compiled with my lock_timeout patch, the 32-bit
was without.

64-bit, connect to localhost:

C:\Users\Ákos\Desktop\PG93>bin\psql
psql: could not connect to server: Operation would block
(0x00002733/10035)
Is the server running on host "localhost" (::1) and accepting
TCP/IP connections on port 5432?
could not connect to server: Operation would block (0x00002733/10035)
Is the server running on host "localhost" (127.0.0.1) and
accepting
TCP/IP connections on port 5432?

64-bit, connect to own IP:

C:\Users\Ákos\Desktop\PG93>bin\psql -h 192.168.1.4
psql: could not connect to server: Operation would block
(0x00002733/10035)
Is the server running on host "192.168.1.4" and accepting
TCP/IP connections on port 5432?

32-bit, connect to own IP:

C:\Users\Ákos\Desktop\PG93-32>bin\psql -h 192.168.1.4
psql: could not connect to server: Operation would block
(0x00002733/10035)
Is the server running on host "192.168.1.4" and accepting
TCP/IP connections on port 5432?

Does it ring a bell for someone?

Unfortunately, I won't have time to do anything with my lock_timeout
patch
for about 3 weeks. Does anyone have a little spare time to test it on
Windows?
The patch is here, it still applies to HEAD without rejects or fuzz:
/messages/by-id/506C0854.7090008@cybertec.at

Yes it rings a bell. See
<http://people.planetpostgresql.org/andrew/index.php?/archives/264-Cross-compiling-PostgreSQL-for-WIndows.html&gt;

Cross-compiling is not really a supported platform. Why don't you just
build natively? This is know to work as shown by the buildfarm animals
doing it successfully.

cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Saturday, January 19, 2013 4:13 AM Boszormenyi Zoltan wrote:

Hi,

Unfortunately, I won't have time to do anything with my lock_timeout patch
for about 3 weeks. Does anyone have a little spare time to test it on Windows?

I shall try to do it, probably next week.
Others are also welcome to test the patch.

With Regards,
Amit Kapila.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

2013-01-19 01:13 keltezéssel, Andrew Dunstan írta:

On 01/18/2013 05:43 PM, Boszormenyi Zoltan wrote:

Hi,

using the MinGW cross-compiled PostgreSQL binaries from Fedora 18,
I get the following error for both 32 and 64-bit compiled executables.
listen_addresses = '*' and "trust" authentication was set for both.
The firewall was disabled for the tests and the server logs "incomplete startup packet".
The 64-bit version was compiled with my lock_timeout patch, the 32-bit
was without.

64-bit, connect to localhost:

C:\Users\Ákos\Desktop\PG93>bin\psql
psql: could not connect to server: Operation would block (0x00002733/10035)
Is the server running on host "localhost" (::1) and accepting
TCP/IP connections on port 5432?
could not connect to server: Operation would block (0x00002733/10035)
Is the server running on host "localhost" (127.0.0.1) and accepting
TCP/IP connections on port 5432?

64-bit, connect to own IP:

C:\Users\Ákos\Desktop\PG93>bin\psql -h 192.168.1.4
psql: could not connect to server: Operation would block (0x00002733/10035)
Is the server running on host "192.168.1.4" and accepting
TCP/IP connections on port 5432?

32-bit, connect to own IP:

C:\Users\Ákos\Desktop\PG93-32>bin\psql -h 192.168.1.4
psql: could not connect to server: Operation would block (0x00002733/10035)
Is the server running on host "192.168.1.4" and accepting
TCP/IP connections on port 5432?

Does it ring a bell for someone?

Unfortunately, I won't have time to do anything with my lock_timeout patch
for about 3 weeks. Does anyone have a little spare time to test it on Windows?
The patch is here, it still applies to HEAD without rejects or fuzz:
/messages/by-id/506C0854.7090008@cybertec.at

Yes it rings a bell. See
<http://people.planetpostgresql.org/andrew/index.php?/archives/264-Cross-compiling-PostgreSQL-for-WIndows.html&gt;

The strange thing is that I have used cross-compiled build
during Fedora 16 prime time (using the mingw-w64 test repository) and
early Fedora 17 using the mingw32-* and ming64-* GCC packages
that were pulled from the above mentioned repository. It was the last time
I tested PG on Windows and it worked. I could connect to it both locally
and from my Linux PC.

Cross-compiling is not really a supported platform. Why don't you just build natively?
This is know to work as shown by the buildfarm animals doing it successfully.

Because I don't have a mingw setup on Windows. (Sorry.)

--
----------------------------------
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt, Austria
Web: http://www.postgresql-support.de
http://www.postgresql.at/

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

2013-01-19 06:52 keltezéssel, Amit kapila írta:

On Saturday, January 19, 2013 4:13 AM Boszormenyi Zoltan wrote:

Hi,

Unfortunately, I won't have time to do anything with my lock_timeout patch
for about 3 weeks. Does anyone have a little spare time to test it on Windows?

I shall try to do it, probably next week.
Others are also welcome to test the patch.

Thanks very much in advance.

--
----------------------------------
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt, Austria
Web: http://www.postgresql-support.de
http://www.postgresql.at/

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

2013-01-19 01:13 keltezéssel, Andrew Dunstan írta:

On 01/18/2013 05:43 PM, Boszormenyi Zoltan wrote:

Hi,

using the MinGW cross-compiled PostgreSQL binaries from Fedora 18,
I get the following error for both 32 and 64-bit compiled executables.
listen_addresses = '*' and "trust" authentication was set for both.
The firewall was disabled for the tests and the server logs "incomplete startup packet".
The 64-bit version was compiled with my lock_timeout patch, the 32-bit
was without.

64-bit, connect to localhost:

C:\Users\Ákos\Desktop\PG93>bin\psql
psql: could not connect to server: Operation would block (0x00002733/10035)
Is the server running on host "localhost" (::1) and accepting
TCP/IP connections on port 5432?
could not connect to server: Operation would block (0x00002733/10035)
Is the server running on host "localhost" (127.0.0.1) and accepting
TCP/IP connections on port 5432?

64-bit, connect to own IP:

C:\Users\Ákos\Desktop\PG93>bin\psql -h 192.168.1.4
psql: could not connect to server: Operation would block (0x00002733/10035)
Is the server running on host "192.168.1.4" and accepting
TCP/IP connections on port 5432?

32-bit, connect to own IP:

C:\Users\Ákos\Desktop\PG93-32>bin\psql -h 192.168.1.4
psql: could not connect to server: Operation would block (0x00002733/10035)
Is the server running on host "192.168.1.4" and accepting
TCP/IP connections on port 5432?

Does it ring a bell for someone?

Unfortunately, I won't have time to do anything with my lock_timeout patch
for about 3 weeks. Does anyone have a little spare time to test it on Windows?
The patch is here, it still applies to HEAD without rejects or fuzz:
/messages/by-id/506C0854.7090008@cybertec.at

Yes it rings a bell. See
<http://people.planetpostgresql.org/andrew/index.php?/archives/264-Cross-compiling-PostgreSQL-for-WIndows.html&gt;

I wanted to add a comment to this blog entry but it wasn't accepted.
Here it is:

It doesn't work under Wine, see:
http://www.winehq.org/pipermail/wine-users/2013-January/107008.html

But pg_config works so other PostgreSQL clients can also be built using the cross compiler.

Cross-compiling is not really a supported platform. Why don't you just build natively?
This is know to work as shown by the buildfarm animals doing it successfully.

cheers

andrew

--
----------------------------------
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt, Austria
Web: http://www.postgresql-support.de
http://www.postgresql.at/

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 01/19/2013 02:36 AM, Boszormenyi Zoltan wrote:

Cross-compiling is not really a supported platform. Why don't you
just build natively? This is know to work as shown by the buildfarm
animals doing it successfully.

Because I don't have a mingw setup on Windows. (Sorry.)

A long time ago I had a lot of sympathy with this answer, but these days
not so much. Getting a working mingw/msys environment sufficient to
build a bare bones PostgreSQL from scratch is both cheap and fairly
easy. The improvements that mingw has made in its install process, and
the presence of cheap or free windows instances in the cloud combine to
make this pretty simple. But since it's still slightly involved here is
how I constructed one such this morning:

* Create an Amazon t1.micro spot instance of
Windows_Server-2008-SP2-English-64Bit-Base-2012.12.12 (ami-554ac83c)
(current price $0.006 / hour)
* get the credentials and log in using:
o rdesktop -g 80% -u Administrator -p 'password' amazon-hostname
* turn off annoying IE security enhancements, and fire up IE
* go to
<http://sourceforge.net/projects/mingw/files/Installer/mingw-get-inst/&gt;
and download latest mingw-get-inst
* run this - make sure to select the Msys and the developer toolkit in
addition to the C compiler
* navigate in explorer or a command window to \Mingw\Msys\1.0 and run
msys.bat
* run this command to install some useful packages:
o mingw-get install msys-wget msys-rxvt msys-unzip
* close that window
* open a normal command window and run the following to create an
unprivileged user and open an msys window as that user:
o net user pgrunner SomePw1234 /add
o runas /user:pgrunner "cmd /c \mingw\msys\1.0\msys.bat --rxvt"
* in the rxvt window run:
o wget
http://ftp.postgresql.org/pub/snapshot/dev/postgresql-snapshot.tar.gz
o tar -z -xf postgresql-snapshot.tar.gz
o wget
"http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Automated%20Builds/mingw-w64-bin_i686-mingw_20111220.zip/download&quot;
o mkdir /mingw64
o cd /mingw64
o unzip ~/mingw-w64-bin_i686-mingw_20111220.zip
o cd ~/postgresql-9.3devel
o export PATH=/mingw64/bin:$PATH
o ./configure --host=x86_64-w64-mingw32 --without-zlib && make &&
make check
+ ( make some coffee and do the crossword or read War and
Peace - this can take a while)

Of course, for something faster you would pick a rather more expensive
instance than t1.micro (say, m1.large, which usually has a spot price of
$0.03 to $0.06 per hour), and if you're going to do this a lot you'll
stash your stuff on an EBS volume that you can remount as needed, or
zip it up and put it on S3, and then just pull it and unpack it in one
hit from there. And there's barely enough room left on the root file
system to do what's above anyway. But you can get the idea from this.
Note that we no longer need to look elsewhere for extra tools like flex
and bison as we once did - the ones that come with modern Msys should
work just fine.

If you want more build features (openssl, libxml, libxslt, perl, python
etc) then there is extra work to do in getting hold of those. But then
cross-compiling for those things might not be easy either.

Somebody more adept at automating Amazon than I am should be able to
automate most or all of this.

Anyway that should be just about enough info for just about any
competent developer to get going, even if they have never touched
Windows. (No doubt one or two people will want to quibble with what I've
done. That's fine - this is a description, not a prescription.)

cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 01/19/2013 02:51 AM, Boszormenyi Zoltan wrote:

Yes it rings a bell. See
<http://people.planetpostgresql.org/andrew/index.php?/archives/264-Cross-compiling-PostgreSQL-for-WIndows.html&gt;

I wanted to add a comment to this blog entry but it wasn't accepted.

The blog is closed for comments. I have moved to a new blog, and this is
just there for archive purposes.

Here it is:

It doesn't work under Wine, see:
http://www.winehq.org/pipermail/wine-users/2013-January/107008.html

But pg_config works so other PostgreSQL clients can also be built
using the cross compiler.

If you want to target Wine I think you're totally on your own.

cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

2013-01-20 00:15 keltezéssel, Andrew Dunstan írta:

On 01/19/2013 02:51 AM, Boszormenyi Zoltan wrote:

Yes it rings a bell. See
<http://people.planetpostgresql.org/andrew/index.php?/archives/264-Cross-compiling-PostgreSQL-for-WIndows.html&gt;

I wanted to add a comment to this blog entry but it wasn't accepted.

The blog is closed for comments. I have moved to a new blog, and this
is just there for archive purposes.

Here it is:

It doesn't work under Wine, see:
http://www.winehq.org/pipermail/wine-users/2013-January/107008.html

But pg_config works so other PostgreSQL clients can also be built
using the cross compiler.

If you want to target Wine I think you're totally on your own.

Yes, I know, it was only an attempt. The user's
administrator privilege under Wine is a showstopper.

cheers

andrew

--
----------------------------------
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt, Austria
Web: http://www.postgresql-support.de
http://www.postgresql.at/

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

2013-01-19 21:15 keltezéssel, Andrew Dunstan írta:

On 01/19/2013 02:36 AM, Boszormenyi Zoltan wrote:

Cross-compiling is not really a supported platform. Why don't you
just build natively? This is know to work as shown by the buildfarm
animals doing it successfully.

Because I don't have a mingw setup on Windows. (Sorry.)

A long time ago I had a lot of sympathy with this answer, but these
days not so much.

I didn't ask for sympathy. :-) I am just on a totally different
project until 9th February and I am also far away from my desk.
So I can't even attempt to install Windows+mingw inside Qemu/KVM.

Best regards,
Zoltán Böszörményi

--
----------------------------------
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt, Austria
Web: http://www.postgresql-support.de
http://www.postgresql.at/

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Sat, Jan 19, 2013 at 12:15 PM, Andrew Dunstan <andrew@dunslane.net> wrote:

On 01/19/2013 02:36 AM, Boszormenyi Zoltan wrote:

A long time ago I had a lot of sympathy with this answer, but these days not
so much. Getting a working mingw/msys environment sufficient to build a bare
bones PostgreSQL from scratch is both cheap and fairly easy. The
improvements that mingw has made in its install process, and the presence of
cheap or free windows instances in the cloud combine to make this pretty
simple. But since it's still slightly involved here is how I constructed
one such this morning:

I've used this description, skipping the Amazon part and putting it
directly on my Windows computer, and it worked.

Except bin/pg_ctl does not work. It just silently exits without doing
anything, so I have to use bin/postgres to start the database (which
is what "make check" uses anyway, so not a problem if you just want
make check). Is that just me or is that a known problem? I've seen
some discussion from 2004, but didn't find a conclusion.

What advantages does mingw have over MSVC? Is it just that it is
cost-free, or is it easier to use mingw than MSVC for someone used to
building on Linux? (mingw certainly does not seem to have the
advantage of being fast!)

Would you like to put this somewhere on wiki.postgresql.org, or would
you mind if I do so?

Thanks for the primer,

Jeff

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 01/24/2013 01:44 PM, Jeff Janes wrote:

On Sat, Jan 19, 2013 at 12:15 PM, Andrew Dunstan <andrew@dunslane.net> wrote:

On 01/19/2013 02:36 AM, Boszormenyi Zoltan wrote:
A long time ago I had a lot of sympathy with this answer, but these days not
so much. Getting a working mingw/msys environment sufficient to build a bare
bones PostgreSQL from scratch is both cheap and fairly easy. The
improvements that mingw has made in its install process, and the presence of
cheap or free windows instances in the cloud combine to make this pretty
simple. But since it's still slightly involved here is how I constructed
one such this morning:

I've used this description, skipping the Amazon part and putting it
directly on my Windows computer, and it worked.

Except bin/pg_ctl does not work. It just silently exits without doing
anything, so I have to use bin/postgres to start the database (which
is what "make check" uses anyway, so not a problem if you just want
make check). Is that just me or is that a known problem? I've seen
some discussion from 2004, but didn't find a conclusion.

Did you copy libpq.dll from the lib directory to the bin directory? If
not, try that and see if it fixes the problem.

What advantages does mingw have over MSVC? Is it just that it is
cost-free, or is it easier to use mingw than MSVC for someone used to
building on Linux? (mingw certainly does not seem to have the
advantage of being fast!)

See Craig's email today about problems with SDKs and availabilty of

Would you like to put this somewhere on wiki.postgresql.org, or would
you mind if I do so?

Thanks for the primer,

Jeff

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 01/24/2013 02:41 PM, Andrew Dunstan wrote:

What advantages does mingw have over MSVC? Is it just that it is
cost-free, or is it easier to use mingw than MSVC for someone used to
building on Linux? (mingw certainly does not seem to have the
advantage of being fast!)

See Craig's email today about problems with SDKs and availabilty of

Not sure what happened there.

... availability of free 64 bit MSVC compilers.

Also, some third party libraries are built with the Mingw compilers and
it's often best not to switch if you can help it.

Would you like to put this somewhere on wiki.postgresql.org, or would
you mind if I do so?

Please go for it.

cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 01/25/2013 02:44 AM, Jeff Janes wrote:

What advantages does mingw have over MSVC? Is it just that it is
cost-free, or is it easier to use mingw than MSVC for someone used to
building on Linux? (mingw certainly does not seem to have the
advantage of being fast!)

As far as I'm concerned, the only advantages of MinGW are:

- Mostly compatible with the autotools/gmake toolchain via msys; and
- Not subject to Microsoft's whims regarding zero-cost access to toolchains

I don't particularly like autotools and think that using it on Windows
is pretty ugly. We need msys anyway because our build process uses bison
and flex and at the present time there are quality native Windows ports
of these tools, but there's no fundamental reason they couldn't run
without msys.

The greater appeal is that MinGW means that we're not totally dependent
on Microsoft's whims when it comes to free access to the toolchain. They
have a spotty history there.

There was no free access to Visual Studio compilers until 2004, with the
release of vctoolkit2003 (which has now vanished). They then added
compilers to the Windows SDK starting in (IIRC) 6.0a, through to 7.1
(Windows 7 and .NET 4.5). Those compilers have been removed from the SDK
as of the Windows 8 SDK. The other way to get Microsoft compilers is
from Visual Studio. This usually expensive product was released as a
free-to-use Express version with VC Express 2005. It was a dog of a
thing that required manual registry hacking and/or environment setup and
the manual addition of an SDK to make work. VC Express 2008 provided an
integrated installer, but also removed some debugging facilities. VC
Express 2010 removed more debugging features. Then with VC 2012
Microsoft announced that there would be no 2012 Express edition and that
everybody should convert their apps to the new Metro system for which
free a toolchain would be available. They went back on that under
community pressure and released VC Express 2012, which has many of the
debugging features restored and works well - but who knows if it'll see
any further updates.

All the Visual Studio Express editions require activation to use them,
though this activation is free. Once you have an activation code it's
valid forever, but there's no guarantee the servers will remain
available to generate new codes, so you'd better keep them written down.

Microsoft don't maintain old SDKs and VC Express editions much, if at
all, so installing and using older SDKs gets more complicated over time.
Take VC Express 2010, until recently the newest edition available:

- Uninstall any Visual Studio 2010 redists that're installed, taking
note of the versions
- Install VC Express 2010
- Install VC Express 2010 SP1
- Install VC Express 2010 SP1 Compiler Pack
- Download and reinstall any newer redists that you uninstalled, so your
apps keep working.

.... and it looks like having VC Express 2010 installed might partly
break VC 2012; I'm still unsure of exactly what caused that.

We can not fix any of these problems, nor can we update the toolsets to
run on newer Windows versions. So if we support only Visual Studio,
we're extremely dependent on the uncertain future of the free Microsoft
toolchain.

For that reason, even though it's not a great build environment and on
Windows not a great compiler, MinGW support is important.

If you notice issues with the MinGW builds, please report them so
regression test coverage can be improved. Hardly anyone uses them but
like the fire department, one day if you stop supporting them you really
regret it.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 01/25/2013 04:08 AM, Andrew Dunstan wrote:

On 01/24/2013 02:41 PM, Andrew Dunstan wrote:

What advantages does mingw have over MSVC? Is it just that it is
cost-free, or is it easier to use mingw than MSVC for someone used to
building on Linux? (mingw certainly does not seem to have the
advantage of being fast!)

See Craig's email today about problems with SDKs and availabilty of
free 64 bit MSVC compilers.

Also, some third party libraries are built with the Mingw compilers
and it's often best not to switch if you can help it.

That's a trade-off; they're often not available in 64-bit, so you
usually land up needing to rebuild them for 64-bit anyway, and the mingw
64 bit toolchain seems to be a bit broken.

As for 64-bit MS compilers - at the moment the current MSVC 64-bit
compilers are available for free as cross-compilers. The rather bizarre
situation is that you have a 64-bit host OS running 32-bit compilers
under Wow64, producing 64-bit binaries as output. This seems to be quite
transparent to the build process when on a 64-bit host, as the host can
execute the cross-compiled binaries directly, so it isn't like a normal
cross-compile where you have to differentiate between host- and target-
executables.

So, while no native 64-bit compilers are available for free as part of
Visual Studio Express 2012 (11), it doesn't matter much. The issue is
more that it's very much Microsoft's whim whether they release compilers
at all and if so, which ones, when and how.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

So, while no native 64-bit compilers are available for free as part of
Visual Studio Express 2012 (11), it doesn't matter much. The issue is
more that it's very much Microsoft's whim whether they release compilers
at all and if so, which ones, when and how.

I think I have a pretty vanilla Visual Studio Express 2012 for Desktop and:

C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin\x86_amd64>.\cl
Microsoft (R) C/C++ Optimizing Compiler Version 17.00.51106.1 for x64
Copyright (C) Microsoft Corporation. All rights reserved.

usage: cl [ option... ] filename... [ /link linkoption... ]

C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin\x86_amd64>

Am I misunderstanding the discussion here?

Isn't that the 64-bit tool suite?

Does anyone care if the compiler is a 64 bit binary itself?

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 01/27/2013 12:04 AM, james wrote:

So, while no native 64-bit compilers are available for free as part of
Visual Studio Express 2012 (11), it doesn't matter much. The issue is
more that it's very much Microsoft's whim whether they release compilers
at all and if so, which ones, when and how.

I think I have a pretty vanilla Visual Studio Express 2012 for Desktop
and:

C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin\x86_amd64>.\cl
Microsoft (R) C/C++ Optimizing Compiler Version 17.00.51106.1 for x64
Copyright (C) Microsoft Corporation. All rights reserved.

usage: cl [ option... ] filename... [ /link linkoption... ]

C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin\x86_amd64>

Am I misunderstanding the discussion here?

Yep, that's a cross-compiler, hence "x86_amd64". As I said, it doesn't
actually matter very much on an x64 host as the target arch binaries run
fine on the host arch. The only reason you'd need the native 64-bit
compiler is if you're compiling huge programs that cause the 32-bit to
64-bit cross-compiler to run out of memory. Not an issue for Pg.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Saturday, January 19, 2013 11:23 AM Amit kapila wrote:

On Saturday, January 19, 2013 4:13 AM Boszormenyi Zoltan wrote:

Hi,

Unfortunately, I won't have time to do anything with my lock_timeout

patch

for about 3 weeks. Does anyone have a little spare time to test it on

Windows?

I shall try to do it, probably next week.
Others are also welcome to test the patch.

I have carried out some windows testing of the lock timeout patch.

The extra tests which are carried out on the patch are attached in the mail.

Some observations on the patch:

1. Patch needs a rebase as it causing some rejections.
2. regress check failed because the expected ".out" file is not updated
properly.

Regards,
Hari babu.

2013-01-28 15:20 keltezéssel, Hari Babu írta:

On Saturday, January 19, 2013 11:23 AM Amit kapila wrote:

On Saturday, January 19, 2013 4:13 AM Boszormenyi Zoltan wrote:

Hi,

Unfortunately, I won't have time to do anything with my lock_timeout

patch

for about 3 weeks. Does anyone have a little spare time to test it on

Windows?

I shall try to do it, probably next week.
Others are also welcome to test the patch.

I have carried out some windows testing of the lock timeout patch.

Thanks very much. It means it didn't crash for you and
it waited the expected amount of time as well.

The extra tests which are carried out on the patch are attached in the mail.

The patch itself contained regression tests to run by itself
and compete with statement_timeout as well, although
it waits only 2 seconds instead of 60 as in your test.

Some observations on the patch:

1. Patch needs a rebase as it causing some rejections.

On a fresh GIT pull, it only caused a reject for the documentation
parts of the patch. No other rejects and no fuzz, only line shift
warnings were indicated by the patch. Anyway, a refreshed one
is attached.

2. regress check failed because the expected ".out" file is not updated
properly.

Which regress check failed? The .out file was updated in the patch
for prepared_xacts.sql where the regression tests for lock_timeout
were added. Or do you mean the one for the sql file you sent?

Thanks,
Zoltán Böszörményi

--
----------------------------------
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt, Austria
Web: http://www.postgresql-support.de
http://www.postgresql.at/

2013-01-30 15:29 keltezéssel, Zoltán Böszörményi írta:

2013-01-28 15:20 keltezéssel, Hari Babu írta:

On Saturday, January 19, 2013 11:23 AM Amit kapila wrote:

On Saturday, January 19, 2013 4:13 AM Boszormenyi Zoltan wrote:

Hi,

Unfortunately, I won't have time to do anything with my lock_timeout

patch

for about 3 weeks. Does anyone have a little spare time to test it on

Windows?

I shall try to do it, probably next week.
Others are also welcome to test the patch.

I have carried out some windows testing of the lock timeout patch.

Thanks very much. It means it didn't crash for you and
it waited the expected amount of time as well.

The extra tests which are carried out on the patch are attached in
the mail.

The patch itself contained regression tests to run by itself
and compete with statement_timeout as well, although
it waits only 2 seconds instead of 60 as in your test.

Some observations on the patch:

1. Patch needs a rebase as it causing some rejections.

On a fresh GIT pull, it only caused a reject for the documentation
parts of the patch. No other rejects and no fuzz, only line shift
warnings were indicated by the patch. Anyway, a refreshed one
is attached.

2. regress check failed because the expected ".out" file is not updated
properly.

Which regress check failed? The .out file was updated in the patch
for prepared_xacts.sql where the regression tests for lock_timeout
were added. Or do you mean the one for the sql file you sent?

If the failed regression test is indeed the prepared_xacts.sql that is
in my patch, can you attach the regression.diff file after the failed
"make check"? Thanks.

Thanks,
Zoltán Böszörményi

--
----------------------------------
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt, Austria
Web: http://www.postgresql-support.de
http://www.postgresql.at/