Andrew Dunstan wrote:
Relevant perl code executed by buildfarm:
chdir $pgsql/src/tools/msvc;
@makeout = `build 21`;
chdir $branch_root;
my $status = $? 8;
I know the docs say otherwise, but would it be possible that chdir
somehow resets $? on windows, sometimes,
Dave Page wrote:
If I then
switch to the non-admin user, it can run initdb just fine. However,
that user can't build, because it gets a mysterious failure from
mt.exe. MinGW is even worse - it says it can't run gcc because it
can't run cc1.exe (IIRC), so it fails at the configure stage! All
user) . I can build as the admin user but when I come to run
initdb it fails, complaining that it can't find the postgres
executable.
FYI, this happens on my Win 2000 also.
Maybe a problem with mixed / \ path separators after RestrictExec.
Andreas
---(end of
Andrew Dunstan wrote:
Dave Page wrote:
Perhaps someone would like to tell me how I can remedy these
problems. More importantly, this should be in an FAQ or some such.
Also, I would like to know if we have really tested out on Vista the
privilege surrendering code that is is supposed to
On Mon, 2007-06-25 at 10:01 +0200, Zeugswetter Andreas ADI SD wrote:
synchronous_commit
Idea: Greg Stark
Supporters: Simon, Josh, Tom, Bruce, Florian
There was one more:
asynchronous_commit
Idea: Florian G. Pflug
Supporters: none
But if you are calling the feature that (which imho
synchronous_commit
Idea: Greg Stark
Supporters: Simon, Josh, Tom, Bruce, Florian
There was one more:
asynchronous_commit
Idea: Florian G. Pflug
Supporters: none
But if you are calling the feature that (which imho is good), the guc
might as well get that name.
Andreas
Magnus Hagander wrote:
Running the same test from the buildfarm script on the same machine, and it
picks up the error and reports it just fine.
(http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=skylarkdt=2007-06-25%2008:28:31)
I ran on Baiji (renaming the zlib directory, instead of the .lib as
On Sun, Jun 24, 2007 at 08:24:43PM -0400, Andrew Dunstan wrote:
Magnus Hagander wrote:
Andrew Dunstan wrote:
I am still very unhappy about the way the MSVC builds work. Although we
have managed to make it sort of work with the buildfarm script, it is
distinctly fragile. Last night,
Simon Riggs wrote:
So, although its a knife edge decision, I'd say go with
synchronous_commit = off.
I agree - I'm not entirely sure why but it just feels more natural than
asynchronous_commit = on. Plus the reasons you give seem valid.
Regards, Dave
---(end of
Dave Page wrote:
I'm going to run on my Win2K3
animal in a minute - that one runs VC++ Express, unlike Baiji and
Skylark which I believe are both 'proper' Visual Studio. Will report
back when it's done.
Yep, it failed at make as well, and reported it appropriately to the BF.
Regards, Dave
I would like to inform, that New Zealand changed DST rules and new
timezone files are available. See
http://www.dia.govt.nz/diawebsite.nsf/wpg_URL/Services-Daylight-Saving-Daylight-saving-to-be-extended
Patch for head attached. I kept zic.c untouched, but I think it would be
nice to update
On Mon, Jun 25, 2007 at 11:42:28PM +1200, Eddie Stanley wrote:
Hi,
I spent the best part of the day trying to work this out - I was working on a
system setup with PG 8.2, and wanted to work with 8.3 for development.
I installed as follows:
1. CVS checkout
2. ./configure
Hi,
I spent the best part of the day trying to work this out - I was working on a
system setup with PG 8.2, and wanted to work with 8.3 for development.
I installed as follows:
1. CVS checkout
2. ./configure prefix=~/install_dir
3. gmake prefix=~/install_dir
4. gmake install
Dave Page wrote:
Dave Page wrote:
I'm going to run on my Win2K3 animal in a minute - that one runs VC++
Express, unlike Baiji and Skylark which I believe are both 'proper'
Visual Studio. Will report back when it's done.
Yep, it failed at make as well, and reported it appropriately to the
On 6/25/07, Tom Lane [EMAIL PROTECTED] wrote:
Well, it's not hard at all to find chunks of English text that have
embedded bits of French, Spanish, or what-have-you, but that's not an
argument for trying to intermix the stemmers. I doubt that such simple
bits of program could tell the language
Magnus Hagander wrote:
Can you run the build in broken mode but *without* using the buildfarm
scripts, and see what errorlevel you get? Meaning:
build.bat
... wait ...
echo %errorlevel%
It should output 1 if that part works, 0 if it fails. That'll tell us if
the problem is in the bf or if
On Mon, Jun 25, 2007 at 10:06:57AM -0400, Andrew Dunstan wrote:
Magnus Hagander wrote:
Can you run the build in broken mode but *without* using the buildfarm
scripts, and see what errorlevel you get? Meaning:
build.bat
... wait ...
echo %errorlevel%
It should output 1 if that part
I'm trying to understand what a soft deadlock is as described by deadlock.c.
As best I understand if a process, A, is waiting for a lock and is being
blocked only because someone, B, is ahead of it in the queue but hasn't been
granted the conflicting lock we want to jump A ahead of B.
So if i
Magnus Hagander wrote:
As for perl, I'm probably not on the very latest, but it's not so old. I'm
on:
This is perl, v5.8.8 built for MSWin32-x64-multi-thread
(with 33 registered patches, see perl -V for more detail)
Dave - what version are you on?
This is perl, v5.8.8 built for
Zdenek Kotala [EMAIL PROTECTED] writes:
I would like to inform, that New Zealand changed DST rules and new
timezone files are available. See
http://www.dia.govt.nz/diawebsite.nsf/wpg_URL/Services-Daylight-Saving-Daylight-saving-to-be-extended
Patch for head attached.
We do not patch those
Magnus Hagander [EMAIL PROTECTED] writes:
I was actually about to post on this just a couple of days ago - it seems
pgxs really needs pg_config to be in your PATH.
Correct --- how else is it going to find out where the installation is?
Eddie's proposed solution is of course circular
Magnus Hagander wrote:
cmd.exe from Windows - I assume you haven't installed some funky addon
special command interpreter? In that case, it should be the same. So I
have:
Microsoft Windows [Version 5.2.3790]
(C) Copyright 1985-2003 Microsoft Corp.
Hmm. Mine says 5.1.2600, which seems
Mike Rylander [EMAIL PROTECTED] writes:
I can certainly understand the benefit of making the default
configuration a simple locale to language map, but there are
definitely uses for searching using different stemmers/stop-lists even
within the same corpus/index. So, as a datapoint for the
Tom Lane wrote:
Zdenek Kotala [EMAIL PROTECTED] writes:
I would like to inform, that New Zealand changed DST rules and new
timezone files are available. See
http://www.dia.govt.nz/diawebsite.nsf/wpg_URL/Services-Daylight-Saving-Daylight-saving-to-be-extended
Patch for head attached.
We
On Mon, Jun 25, 2007 at 10:43:37AM -0400, Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
I was actually about to post on this just a couple of days ago - it seems
pgxs really needs pg_config to be in your PATH.
Correct --- how else is it going to find out where the installation
On Mon, Jun 25, 2007 at 10:45:00AM -0400, Andrew Dunstan wrote:
Magnus Hagander wrote:
cmd.exe from Windows - I assume you haven't installed some funky addon
special command interpreter? In that case, it should be the same. So I
have:
Microsoft Windows [Version 5.2.3790]
(C) Copyright
Andrew Dunstan wrote:
Hmm. Mine says 5.1.2600, which seems to be quite old. I'll see about
updating ... the strange thing is I'm pretty sure I've seen this on
other more up to date machines.
You can't update that unless you upgrade to Windows 2003 or Vista.
That's the XP command shell.
On 6/25/07, Tom Lane [EMAIL PROTECTED] wrote:
Mike Rylander [EMAIL PROTECTED] writes:
I can certainly understand the benefit of making the default
configuration a simple locale to language map, but there are
definitely uses for searching using different stemmers/stop-lists even
within the
Dave Page wrote:
Dave Page wrote:
If I then
switch to the non-admin user, it can run initdb just fine. However,
that user can't build, because it gets a mysterious failure from
mt.exe. MinGW is even worse - it says it can't run gcc because it
can't run cc1.exe (IIRC), so it fails at the
Magnus Hagander [EMAIL PROTECTED] writes:
On Mon, Jun 25, 2007 at 10:43:37AM -0400, Tom Lane wrote:
Correct --- how else is it going to find out where the installation is?
You can specify the full path in the command to pg_config in your Makefile.
It'd be neat if the makefile could fint that
Gregory Stark [EMAIL PROTECTED] writes:
I'm trying to understand what a soft deadlock is as described by deadlock.c.
As best I understand if a process, A, is waiting for a lock and is being
blocked only because someone, B, is ahead of it in the queue but hasn't been
granted the conflicting
Magnus Hagander wrote:
Can we change that or make it switchable? I'd be happy to provide an
environment variable like RUNNING_BUILDFARM if that would help.
We could, but it seems very ugly. And again, it's *not* required for
buildfarm on my or Daves machines. So I'd rather like to know
Magnus Hagander wrote:
So it might be worthwhile to see if this is something that happens on =
XP, and works on = 2003. Dave, did you test on any server OS other than
2003, or any client that's XP or earlier?
No, my testing was only on 2k3 and vista.
/D
---(end of
This seems odd. It's not deciding that it's ambiguous or coming from another
datatype for which no implicit cast exists. It knows perfectly well that it
wants to convert to text but fails?
postgres=# select 'a'||b from (select 'b' as b) as x;
ERROR: failed to find conversion function from
On Sat, Jun 23, 2007 at 06:14:23PM +0200, Magnus Hagander wrote:
The benefit would be that PostgreSQL would be secure by default. Which
we are *not* today.
To achieve the secure by default feature that you want (and I like
the scare-quotes -- I agree with those that think this adds no real
On Mon, 25 Jun 2007 17:56:28 +0100
Gregory Stark [EMAIL PROTECTED] wrote:
This seems odd. It's not deciding that it's ambiguous or coming from another
datatype for which no implicit cast exists. It knows perfectly well that it
wants to convert to text but fails?
postgres=# select 'a'||b
Gregory Stark [EMAIL PROTECTED] writes:
This seems odd. It's not deciding that it's ambiguous or coming from another
datatype for which no implicit cast exists. It knows perfectly well that it
wants to convert to text but fails?
postgres=# select 'a'||b from (select 'b' as b) as x;
ERROR:
Andrew Sullivan [EMAIL PROTECTED] writes:
To achieve the secure by default feature that you want (and I like
the scare-quotes -- I agree with those that think this adds no real
security, but I think you're right to worry about the perception
angle in this case), why not have a ./configure
Fabien COELHO [EMAIL PROTECTED] writes:
ifdef USE_PGXS
PGXS := $(shell pg_config --pgxs)
include $(PGXS)
but something like
ifdef USE_PGXS
PG_CONFIG := pg_config
PGXS := $(shell $(PG_CONFIG) --pgxs)
include $(PGXS)
That would break existing Makefiles that use the please take the
ifdef USE_PGXS
PGXS := $(shell pg_config --pgxs)
include $(PGXS)
but something like
ifdef USE_PGXS
PG_CONFIG := pg_config
PGXS := $(shell $(PG_CONFIG) --pgxs)
include $(PGXS)
to sync these invocations of pg_config with the ones in
Makefile.global. I'm not sure though how to get this setting
Dear Eddie,
MODULES = example
PGXS := $(shell ~/install_dir/bin/pg_config --pgxs)
This is indeed not the intented use of pgxs: it breaks a desirable
property of the makefile that is should be generic wrt postgresql, that
is not particular to an installation.
You are really expected to
Dear Tom,
That would break existing Makefiles that use the please take the first
pg_config in the path feature, which rather make sense (it just means
that you want the extension for your current postgresql).
How would it break them? The default definition is still PG_CONFIG =
pg_config,
Fabien COELHO [EMAIL PROTECTED] writes:
With the assumption that the above that one refered to the PG_CONFIG
macro definition in Makefile.global. As existing extension makefiles do
not defined PG_CONFIG, relying on one would break them wrt future
releases?
Ah, I see. I was thinking in
On Sun, 2007-06-24 at 13:23 -0400, Andrew Dunstan wrote:
(cut)
On a somewhat related note, I have had spectacular lack of success in
getting either MSVC or MinGW builds to work on Vista - so much so that I
have currently abandoned my attempts on that platform and I resorted to
Mark Cave-Ayland wrote:
This has come up quite recently on the MingW lists - see
http://sourceforge.net/mailarchive/forum.php?thread_name=00fc01c7a0af%
240a037c30%240200a8c0%40AMD2500forum_name=mingw-users for a discussion
of the problem and solution.
Thanks. I've actually got past
On Mon, Jun 25, 2007 at 01:31:52PM -0400, Tom Lane wrote:
Why is that better than the initdb-time option we already have?
Locking down options earlier rather than later is usually not a win.
Like I said, I don't actually think it _is_ better. But it would
solve the problem that some people
Andrew Sullivan [EMAIL PROTECTED] writes:
On Mon, Jun 25, 2007 at 01:31:52PM -0400, Tom Lane wrote:
Why is that better than the initdb-time option we already have?
Locking down options earlier rather than later is usually not a win.
Like I said, I don't actually think it _is_ better. But it
A number of people have complained that it is possible to make a base
backup and then shutdown the server before the last xlog file has been
archived. Others say they would like to be able to make a backup and
know it is complete.
Making the archiver continue while the file is archived can cause
Is protocol version 2 still used by anything? Is there a reason why
this is still supported?
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Chuck McDevitt [EMAIL PROTECTED] writes:
Is protocol version 2 still used by anything? Is there a reason why
this is still supported?
Even if you're not concerned about breaking old clients, I believe that
the JDBC folk are still giving out advice to use ProtocolVersion=2 as
a workaround for
On 6/25/07, Tom Lane [EMAIL PROTECTED] wrote:
Andrew Sullivan [EMAIL PROTECTED] writes:
On Mon, Jun 25, 2007 at 01:31:52PM -0400, Tom Lane wrote:
Why is that better than the initdb-time option we already have?
Locking down options earlier rather than later is usually not a win.
Like I said,
Andrew Hammond [EMAIL PROTECTED] writes:
On 6/25/07, Tom Lane [EMAIL PROTECTED] wrote:
The normal build process for any open-source package is
./configure
make
sudo make install
... now what? OK, time to read the manual ...
Since they presumably don't know about initdb yet, yeah, I
On Jun 25, 2007, at 3:30 AM, Dave Page wrote:
Simon Riggs wrote:
So, although its a knife edge decision, I'd say go with
synchronous_commit = off.
I agree - I'm not entirely sure why but it just feels more natural
than asynchronous_commit = on. Plus the reasons you give seem valid.
On the
Jim Nasby [EMAIL PROTECTED] writes:
I'm wondering if it would be wise to throw a warning at startup if
either sync_commit or fsync were set to off, ideally so that it would
both appear in the logs as well as in output from pg_ctl.
Egad. And no doubt also complain about politically
On Mon, 2007-06-25 at 18:14 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
A simple solution is to introduce a new function:
pg_archive_wait(integer maxwait);
maxwait = 0 means wait forever, otherwise time measured in seconds.
maxwait is redundant; people who want a
55 matches
Mail list logo
