Andrew Dunstan wrote:
Not to my knowledge, but I have no method of testing what's going on,
and I hate guessing like this - in fact this is what has worried me all
along about supporting MSVC builds - we always said we didn't want to
have to have 2 build environments, but now we have two and
Tom Lane wrote:
So I now state fairly confidently that baiji is failing to overwrite
*any* of the installation tree, /share and /bin both, and instead is
testing an installation dating from sometime between May 1 and May 11.
Close. There was an Msys build from the 9th running on port 5432.
Zeugswetter Andreas ADI SD wrote:
Close. There was an Msys build from the 9th running on port 5432.
2) VC++ and Msys builds will both happily start on the same
port at the same time. The first one to start listens on 5432
until it shuts down, at which point the second server takes
over
Andrew Dunstan wrote:
I'll look at the port mess.
Are you running 2 buildfarm members on the same machine? If so, you
should look at using the multi-root factility which is explicitly
designed to avoid clashes of this sort.
Yes, I've got VC++ and Mingw/Msys animals on each of two
Stephen Frost wrote:
* Tom Lane ([EMAIL PROTECTED]) wrote:
There is a related risk even on Unix machines: two postmasters can be
started on the same port number if they have different settings of
unix_socket_directory, and then it's indeterminate which one you will
contact if you connect to
Tom Lane wrote:
Windows seems to treat SO_REUSEADDR in the same
way as SO_REUSEPORT which just seems wrong.
Well, Microsoft getting standards wrong is no surprise. So what do we
want to do about it?
Microsoft did lift that code from BSD many moons ago, so it might be
worth checking if the
Michael Meskes wrote:
On Wed, May 09, 2007 at 12:46:52PM +0100, Dave Page wrote:
Oh, hang on... Vista's new 'security' features include popups that ask
permission from the user before running any installers. One of the more
basic checks they use is the filename - *anything* called setup.exe
Michael Meskes wrote:
On Thu, May 10, 2007 at 11:05:39AM +0100, Dave Page wrote:
P.S.: More on the other problem later.
OK.
Dave, I just committed some small changes to get additional error
logging. Hopefully this enables me to find out where exactly the error
is coming up. If possible
Dave Page wrote:
Michael Meskes wrote:
On Thu, May 10, 2007 at 11:05:39AM +0100, Dave Page wrote:
P.S.: More on the other problem later.
OK.
Dave, I just committed some small changes to get additional error
logging. Hopefully this enables me to find out where exactly the error
is coming up
Hi,
I asked about this before, but the thread got hijacked to discuss
another buildfarm failure :-(. Currently our only Windows Vista
buildfarm member (Vaquita) fails every time (assuming it gets that far)
on ECPG's dt_test and update tests.
I've checked the FS permissions, and see no
Michael Meskes wrote:
Dave, could you please run
insert into date_test ( d , ts ) values ( date '1966-01-17' ,
timestamp '2000-07-12 17:34:29' );
on the Vista system and then select * from date_test;?
According to the logs the insert runs successfully but the select gives
an invalid date
Peter Eisentraut wrote:
Am Mittwoch, 9. Mai 2007 13:46 schrieb Dave Page:
Can we rename the test please?
I'm thinking no. Brain-dead systems should produce brain-dead test results.
And that helps us how exactly, on what will probably be the most widely
used OS in the world within a few
Ned Lilly wrote:
On 5/9/2007 7:46 AM Dave Page wrote:
Oh, hang on... Vista's new 'security' features include popups that ask
permission from the user before running any installers. One of the
more basic checks they use is the filename - *anything* called
setup.exe will cause user
Bruce Momjian wrote:
The idea of the patch number in the subject line works with that
streaming model because it merely marks streams so they can be grouped.
The defining event that marks the stream is a post to the patches list.
We already number posts to the bugs list, so in a way we could
--- Original Message ---
From: Bruce Momjian [EMAIL PROTECTED]
To: PostgreSQL-development pgsql-hackers@postgresql.org
Sent: 05/05/07, 03:00:25
Subject: [HACKERS] New idea for patch tracking
As for #3, again, I don't want us to take on a burdensome patch tracking
process that is
--- Original Message ---
From: Bruce Momjian [EMAIL PROTECTED]
To: Dave Page [EMAIL PROTECTED]
Sent: 05/05/07, 11:06:37
Subject: Re: [HACKERS] New idea for patch tracking
snip tracker outline
Barring a few trivial details, that sounds almost identical to what I
proposed
Josh Berkus wrote:
Tom, Pavel,
Hmm, I see your point. I'm personally satisfied with adding a new
proargmode to solve this as you suggest.
This will break client-side code that looks at proargmode, and I don't
think the argument in favor is strong enough to justify that ...
What kind of
For info, the buildfarm script failed to leave the broken tree behind
again so I was unable to get a dump from the affected index.
Andrew; My run logs show that the script did think it was leaving the
tree behind (it included the 'leaving error trees' text that you asked
me to add to the
Bruce Momjian wrote:
Csaba Nagy wrote:
We have _ample_ evidence that the problem is lack of people able to
review patches, and yet there is this discussion to track patches
better. It reminds me of someone who has lost their keys in an alley,
but is looking for them in the street because the
Magnus Hagander wrote:
Also, last I checked OpenSSL didn't ship with Windows and Kerberos
encryption did.
How long ago did you check? I've been using OpenSSL on windows for many
years. Actually, it was supported just fine on Windows back when it was
added to PostgreSQL *at least*.
I didn't say
Joshua D. Drake wrote:
Well according to himself the last time this came up:
http://archives.postgresql.org/pgsql-hackers/2006-08/msg01253.php
No, he isn't.
The last paragraph of
http://archives.postgresql.org/pgsql-hackers/2007-04/msg01258.php is
somewhat more positive regarding a patch
Bruce Momjian wrote:
Sounds interesting, but I am not sure how that is going to track
multiple versions of the patch,
They could easily be submitted through the web interface as revisions to
the original version.
or changes in the email subject.
We'd need to keep the reference number in
Bruce Momjian wrote:
The bottom line is if you had a system that was 100% perfect in
capturing all information about a patch, it only helps us 2% toward
reviewing the patch, and what is the cost of keeping 100% information?
2% for you or Tom reviewing a recently discussed, run-of-the mill
Josh,
Josh Berkus wrote:
Is there a reason why the system needs to be primarily based on e-mail? I was
thinking that the patch manager would be entirely a web tool, with people
submitting and modifying a patch directly through a web interface. This
would be lots easier to build than an
--- Original Message ---
From: Andrew Dunstan [EMAIL PROTECTED]
To: Josh Berkus [EMAIL PROTECTED]
Sent: 01/05/07, 21:10:07
Subject: Re: [HACKERS] Feature freeze progress report
So if the commercial
backers of PostgreSQL want better management of the project, maybe they
need
Tom Lane wrote:
Dave Page [EMAIL PROTECTED] writes:
I like the idea of having a sync point mid cycle, however, what I'd like
to see even more is an improved system in which we put less pressure on
the few committers we have, and give them more freedom to commit patches
they may
Stefan Kaltenbrunner wrote:
Interesting ... so if you have a new feature (or a number of them) -
that is not directly depending on some sort of new backend feature - in
pgadmin you delay it until the next postgresql mjor release ?
It's not so much that we delay the new features, it's just that
Stefan Kaltenbrunner wrote:
No, but it's exactly the reason why we release with/just before
PostgreSQL. If we were offset by six months, we might find ourselves
having to do compatibility releases mid-cycle for the latest PostgreSQL
release. A change in pg_database such as we had previously
Bruce Momjian wrote:
Tom Lane wrote:
Dave Page [EMAIL PROTECTED] writes:
I like the idea of having a sync point mid cycle, however, what I'd like
to see even more is an improved system in which we put less pressure on
the few committers we have, and give them more freedom to commit patches
Bruce Momjian wrote:
Dave Page wrote:
2) Introduce a new patch management system. I suggest a web interface
through which patches be submitted. This would assign them an ID number,
and forward them to the patches list. The system would track any
responses to the initial email, logging
Heikki Linnakangas wrote:
I like the idea of draining the patch queue mid-way through the release
cycle. That'll hopefully encourage people to submit patches earlier in
the release cycle, knowing they will be reviewed. It'll also give people
working on external projects, drivers and tools, a
Stefan Kaltenbrunner wrote:
This means that there is a huge rush of new code in pgAdmin's
development cycle, right at the time when we should be testing - making
the release process more and more rushed as each release of PostgreSQL
gets more efficient and adds more and more new features.
Tom Lane wrote:
Dave Page [EMAIL PROTECTED] writes:
I've been seeing this failure intermittently on Narwhal HEAD, and once
on 8.1. Other branches have been OK, as have other animals running on
the same physical box. Narwhal-HEAD is run more often than any other
builds however.
Oh
that no one can accidentally use
the non-signal-aware version of pg_usleep in a Windows backend.
--
Dave Page
PostgreSQL Core Team
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org
Andrew Dunstan wrote:
Dave Page wrote:
* The stats collector bug which prevented stats being collected
reliably, thus causing all the expected knock on effects (including
near-total failure of autovacuum). The 8.2 fix for this was dependent
on the redesign of the collector to remove
Tom Lane wrote:
I concur it's too regular to be a hardware issue. The VMware idea is
a bit plausible though. If that's it, we ought to see failures of this
ilk on all four animals sooner or later ...
I've run full disk scans in both Windows VMs, and forced an fsck of the
host just to be on
I've uploaded a preview release of the Windows installer for PostgreSQL
8.3 to http://pgfoundry.org/frs/?group_id=107.
This preview is intended to get some initial testing and feedback on the
new architecture that we intend to use for future installers. In a
nutshell, most of the bundled
This was another occurance of the strange create index failure on
Narwhal - unfortunately, despite having 'keep_error_builds' = 1 in my
BF config it seems to have removed the tree so I can't get the dump that
Tom wanted.
Does anyone know why the keep_error_builds option didn't work in this
case?
Andrew Dunstan wrote:
Dave Page wrote:
This was another occurance of the strange create index failure on
Narwhal - unfortunately, despite having 'keep_error_builds' = 1 in my
BF config it seems to have removed the tree so I can't get the dump that
Tom wanted.
Does anyone know why
I just noticed that the stage logs aren't displayed against MSVC build
hosts as they are for regular hosts, eg:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=mastodondt=2007-04-25%2001:00:02
vs.
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=narwhaldt=2007-04-25%2002:00:03
Is this WIP,
I'm seeing an ECPG-Check failure on Windows Vista - any ideas what might
be causing this?
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=vaquitadt=2007-04-24%2020:00:05
The only other Vista buildfarm member (baiji, on the same physical box)
is running MSVC builds which don't yet test ECPG
Andrew Dunstan wrote:
The problem not beacuse of MSVC, but because of member misconfiguration,
by the look of it. The tar command string will need to be set in the
config file and tar installed. I found that I needed bsdtar for Windows
for this to work. See
Ah, OK, thanks - there was a typo
Michael Meskes wrote:
On Wed, Apr 25, 2007 at 10:47:57AM +0100, Dave Page wrote:
I'm seeing an ECPG-Check failure on Windows Vista - any ideas what might
be causing this?
Hmm, first glance suggests some permission problems.
Yes, that was my thought as well, however I ran cacls down
Andrew Dunstan wrote:
Please don't do that on your buildfarm repo copy (if that's what you
did). You should not touch *anything* inside it. If need to you do this,
make a copy (see later) and alter that.
If you did do this to the buildfarm repo copy, please blow it away so
that buildfarm
Zeugswetter Andreas ADI SD wrote:
Hmm, I'll give it a go when I'm back in the office, but bear
in mind this is a Mingw build on which debugging is nigh-on
impossible.
I use the Snapshot
http://prdownloads.sf.net/mingw/gdb-6.3-2.exe?download from sf.net.
It has some issues, but it is
Dave Page wrote:
If you want to poke at it, I'd suggest changing the ERROR to PANIC
(it's in bufmgr.c) to cause a core dump, run installchecks till you
get a panic, and then look around in the dump to see what you can find.
Well, in typical fashion after 25+ runs this morning there's
Tom Lane wrote:
Dave Page [EMAIL PROTECTED] writes:
I've been seeing this failure intermittently on Narwhal HEAD, and once
on 8.1. Other branches have been OK, as have other animals running on
the same physical box. Narwhal-HEAD is run more often than any other
builds however.
Anyone have
Tom Lane wrote:
Dave Page [EMAIL PROTECTED] writes:
Tom Lane wrote:
If you want to poke at it, I'd suggest changing the ERROR to PANIC
(it's in bufmgr.c) to cause a core dump, run installchecks till you
get a panic, and then look around in the dump to see what you can find.
It'd
I've been seeing this failure intermittently on Narwhal HEAD, and once
on 8.1. Other branches have been OK, as have other animals running on
the same physical box. Narwhal-HEAD is run more often than any other
builds however.
Anyone have any idea what might be wrong? It seems unlikely to be a
New buildfarm member Narwhal is failing the PL regression tests for
Python on REL8_1_STABLE. This appears to be because it's running Python
2.5 (the causes being a deprecated module - whrandom - and some changed
messages).
The former problem was fixed by Peter, and the latter by Tom but both
Tom Lane wrote:
Dave Page [EMAIL PROTECTED] writes:
Andrew Dunstan wrote:
The question in my mind is this: how much do we back-patch to cover new
and incompatible releases of software we depend on?
I guess that depends on the invasiveness - in this case it's a couple of
simple updates
Andrew Dunstan wrote:
The question in my mind is this: how much do we back-patch to cover new
and incompatible releases of software we depend on? Python 2.5 was
released on 19 Sept 2006, long after Postgres 8.1. I guess you could
make a case to say that we should back-patch to the release
Magnus Hagander wrote:
On Thu, Apr 12, 2007 at 12:24:58AM +0200, Peter Eisentraut wrote:
Magnus Hagander wrote:
(FWIW, I had ipv6 on my list of things to make happen, but I didn't
realise it would cause this issue on a machine with ipv6 on it, since
I don't have one)
The IPv6 support is finely
On Windows Vista, IPv6 is enabled by default, and cannot be uninstalled,
or disabled easily on the loopback adaptor. localhost is ::1 by
default, and the enhanced 'security' makes it insanely difficult to edit
the hosts file.
This means that the regression tests fail to run, leaving a
Andrew Dunstan wrote:
Peter Eisentraut wrote:
Am Mittwoch, 11. April 2007 15:36 schrieb Dave Page:
This means that the regression tests fail to run, leaving a
postmaster.log full of 'no pg_hba.conf entry for host ::1' errors.
Should we have initdb enable the ::1 pg_hba.conf trust entry
Magnus Hagander wrote:
On Wed, Apr 11, 2007 at 10:08:36AM -0400, Andrew Dunstan wrote:
Peter Eisentraut wrote:
Am Mittwoch, 11. April 2007 15:36 schrieb Dave Page:
This means that the regression tests fail to run, leaving a
postmaster.log full of 'no pg_hba.conf entry for host ::1' errors
--- Original Message ---
From: Florian G. Pflug [EMAIL PROTECTED]
To: pgsql-hackers@postgresql.org pgsql-hackers@postgresql.org
Sent: 06/04/07, 20:12:39
Subject: [HACKERS] Fate of pgsnmpd
Hi
Does anyone know if pgsnmpd is still actively developed?
The last version (0.1b1) is
--- Original Message ---
From: Stefan Kaltenbrunner [EMAIL PROTECTED]
To: Andrew Dunstan [EMAIL PROTECTED]
Sent: 06/04/07, 15:33:20
Subject: Re: [HACKERS] What X86/X64 OS's do we need coverage for?
yeah improving windows coverage might be a nice thing - some other
I'm awaiting
Magnus Hagander wrote:
On Tue, Apr 03, 2007 at 06:16:26PM +0900, Hiroshi Saito wrote:
Slony-I is still used...Ahh, I have not confirmed it yet.
Slony uses it, yes. It would probably be worthwhile to fix that one as
well, but I haven't looked at how much work that would be.
And to port the
Andrew Dunstan wrote:
So, before an investment of any more time is made by either Abhijit or
myself, I would like to get confirmation that a) there is broad
agreement on the desirability of the feature
Yes, absolutely desirable.
and b) that there is broad
agreement on the general design
Andrew Dunstan wrote:
No loss, but, per previous discussion, it would block and try to get
other backends to collect their outstanding notifications.
Let's say we provide 100Kb for this (which is not a heck of a lot) ,
that the average notification might be, say, 40 bytes of name plus 60
Peter Eisentraut wrote:
Joshua D. Drake wrote:
Funny :). What can I do to help get 8.2.4 branched?
There is no branching involved, but you can look into
src/tools/RELEASE_CHANGES and see what things you want to help with.
Getting a release changes list would be a start.
We're just
Joshua D. Drake wrote:
Dave Page wrote:
Peter Eisentraut wrote:
Joshua D. Drake wrote:
Funny :). What can I do to help get 8.2.4 branched?
There is no branching involved, but you can look into
src/tools/RELEASE_CHANGES and see what things you want to help with.
Getting a release changes
Bruce Momjian wrote:
Peter Eisentraut wrote:
I was hoping that we're deprecating contrib/xml2, so I wouldn't add more
features to it.
Author states:
I understand that XML support is planned and at least partially
implemented for 8.3, but many production instances will be unable (or,
in
Magnus Hagander wrote:
In which case it can simply be because I was building against a libpq
built with MSVC = it had the broken startup code, and you used a mingw
one, which didn't have it.
Maybe - but it does imply it's potentially easy to break code with this
change.
Per the docs, an
Joshua D. Drake wrote:
Christian Bird wrote:
Hi all,
I'm a grad student at UC Davis studying the postgres community and I
wanted to know if some on this list could help me out. I'm studying
the factors that affect people graduating from being mailing list
participant to developers with write
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Well, here's a question. Given the recent discussion re full
disjunction, I'd like to know what sort of commitment we are going to
give people who work on proposed projects.
Um, if you mean are we going to promise to accept a patch
Magnus Hagander wrote:
On Tue, Feb 27, 2007 at 09:21:42AM +, Dave Page wrote:
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Well, here's a question. Given the recent discussion re full
disjunction, I'd like to know what sort of commitment we are going to
give people who work
Magnus Hagander wrote:
Right. We'll just have to live by Googles rule for that part, I'm
talking about the discussions later. Once things are approved, they
should all be handled on the standard mailinglists, IMHO.
Oh, 100% agreed.
Being able to make possibly controversial suggestiosn public
Joshua D. Drake wrote:
2. We have to accept that not everyone wants IRON clad data integrity.
We have many, many options for dealing with that now, including PITR and
REPLICATION.
100% agreed - our own stats collector is extremely similar (in that it
may drop data under high load) to a system
Magnus Hagander wrote:
I've been looking at backporting the stats fix committed to head and 8.2
into 8.1, but realised that it's just not going to work. 8.1 still uses
the dual stats processor stuff, which means that the simplification just
is not possible.
The most obvious result is that
Joshua D. Drake wrote:
Peter Eisentraut wrote:
The issue of XML export has been discussed a few times throughout
history. Right now you've got the HTML output in psql. A few
people have proposed real XML output formats in psql or elsewhere.
I dug out some old code today that implements
?
---
Dave Page wrote:
Dave Page wrote:
I don't object to it in principle, but I think a bit more thought is
needed as to what's the goal. A stupid append option would be enough
for pg_dumpall's current capabilities (ie, text output only
http://developer.postgresql.org/pgdocs/postgres/catalog-pg-opfamily.html
states that
Operator families are described at length in Section 33.14.
which does not seem to be the case. Did it get missed in a commit?
Regards, Dave.
---(end of
Andreas Pflug wrote:
Not much function to re-create here, single
exception is extracting cluster wide data, the -g option, that's why I
mentioned scripting. But apparently this didn't get into pgadmin svn any
more, so I need to retract this proposal.
Eh? Your SCRIPT code is still there - or
Dave Page wrote:
I don't object to it in principle, but I think a bit more thought is
needed as to what's the goal. A stupid append option would be enough
for pg_dumpall's current capabilities (ie, text output only) --- but is
it reasonable to consider generalizing -Fc and -Ft modes to deal
Bruce Momjian wrote:
Right, because even the decision of whether they should be in the queue
is a decision for us. The hold queue additions are less stringent than
the main patch queue.
Isn't that always the case though, not just after FF when the hold queue
starts getting activity again?
Bruce Momjian wrote:
The problem there is that the web site references these, so changing the
URL for every release is odd,
Not a problem though - it's trivial for us to update whatever webpages
link to it.
plus right now both queues are for 8.3.
Well, yeah - that's why it's
--- Original Message ---
From: Tom Lane [EMAIL PROTECTED]
To: Dave Page [EMAIL PROTECTED]
Sent: 1/5/07, 10:48:17 PM
Subject: Re: [HACKERS] -f output file option for pg_dumpall
Wouldn't it be easier/better to re-point stdout at the -f file, and not
touch pg_dump at all?
First
--- Original Message ---
From: Tom Lane [EMAIL PROTECTED]
To: Dave Page [EMAIL PROTECTED]
Sent: 1/5/07, 10:52:37 PM
Subject: Re: [HACKERS] -f output file option for pg_dumpall
I think this will be an exercise in time-wasting, and very possibly
destabilize *both* tools. pg_dump
Peter Eisentraut wrote:
Dave Page wrote:
In pgAdmin we use pg_dump's -f option to write backup files. The IO
streams are redirected to display status and errors etc. in the GUI.
In order to enhance the interface to allow backup of entire clusters
as well as role and tablespace definitions, we
Tom Lane wrote:
Dave Page [EMAIL PROTECTED] writes:
From: Tom Lane [EMAIL PROTECTED]
I think forking a separate
pg_dump for each database is a perfectly fine arrangement, and should be
left alone.
Hmm, would you be happy with my original proposal to add an append option to
pg_dump?
I
Bruce Momjian wrote:
The issue is that the _hold_ patches are for patches that arrived after
feature freeze. The patches that arrived after 8.2 was released don't
go in there because it might cause confusion. I also have to control
how quickly I push out patches from the queue so as not to
Bruce Momjian wrote:
Dave Page wrote:
Bruce Momjian wrote:
The issue is that the _hold_ patches are for patches that arrived after
feature freeze. The patches that arrived after 8.2 was released don't
go in there because it might cause confusion. I also have to control
how quickly I push out
Magnus Hagander wrote:
I discussed this briefly with Robert on IM yesterday - he told me the
account was installer created. Without a PC at the time I couldn't look
into it further :-(
The faq still applies as the most likely reason. It can certainly happen
with the installer created
In pgAdmin we use pg_dump's -f option to write backup files. The IO
streams are redirected to display status and errors etc. in the GUI.
In order to enhance the interface to allow backup of entire clusters as
well as role and tablespace definitions, we need to be able to get
pg_dumpall to write
David Fetter wrote:
This seems a bit like piecemeal reform. Here are some things I'd like to
see that affect this area:
. merge pg_dump and pg_dumpall (e.g. add a flag to pg_dump that says do
the lot)
. multi-db non-text dumps
And while we're about it, can we teach pg_restore to handle text
Andreas Pflug wrote:
Dave Page wrote:
In pgAdmin we use pg_dump's -f option to write backup files. The IO
streams are redirected to display status and errors etc. in the GUI.
In order to enhance the interface to allow backup of entire clusters as
well as role and tablespace definitions, we
Magnus Hagander wrote:
Andreas 'ads' Scherbaum wrote:
Hello all,
a friend of mine ran into a problem installing PostgreSQL 8.0.9 on a
Windows XP Pro machine. Before anyone is asking: it has to be a 8.0.x
version and we even tried to install 8.2 and it did not work.
Ok, the problem is:
Magnus Hagander wrote:
Knut P. Lehre wrote:
Installing postgresql 8.2.0 on Windows XP Pro SP2 using the msi
installer dated 2006-12-04, with libeay32.dll and ssleay32.dll (both
dated 2005-07-06) (and libiconv-2.dll, libintl-2.dll, and libpq.dll)
from a previous installation (of version 8.0.5)
Robert Treat wrote:
Dave: How does PgAdmin handle setting table-specific autovacuum
parameters? (Does it?)
Yes, it adds/removes/edits rows in pg_autovacuum as required.
We do this in phppgadmin too, although I also added a screen that show alist
of entries with schema and table names
Simon Riggs wrote:
On Wed, 2006-12-20 at 09:47 -0500, Jim Nasby wrote:
On the other hand, this would be the only part of the system where
the official interface/API is a system catalog table. Do we really
want to expose the internal representation of something as our API?
That doesn't
Magnus Hagander wrote:
Also, it compiles fine on MSVC. I still haven't managed to get the MingW
build environment working properly on Win64 even for building Win32
apps, so I haven't been able to build it on MingW yet. It *should* work
since it's all standard functions, but might require further
Ted Petrosky wrote:
take a look at this link
http://www.entropy.ch/blog/Software/2006/02/04/PostgreSQL-Universal-Binary-Build-Tips.html
I've seen links to there before, but it always times out for me. As it
is now :-(
I've got your followup email though, so I'll try a build as soon a
Shane Ambler wrote:
# make distclean
# CFLAGS=-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch
i386 LDFLAGS=-Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk -arch ppc
-arch i386 ./configure --with-openssl --prefix=/usr/local
# make all
After reading the Apple tech doc on this
Ted Petrosky wrote:
I am trying to create the libpq.a as a universal binary (both ppc and
intel macs). Does anyone have any information on this process?
I use the following notes to build libpq and the bin/ tools to ship with
pgAdmin. I know it is possible to build the entire server, as a
Ted Petrosky wrote:
Thanks for the reply at last nights cocoahead meeting in NYC I asked
and found a solution for libpq.a.
1. config and make on a ppc
2. config and make on intel
copy and rename the libpq.a from each system to a common directory and
run 'lipo' on them:
lipo libpqppc.a
--- Original Message ---
From: Peter Eisentraut [EMAIL PROTECTED]
To: Jeremy Drake [EMAIL PROTECTED]
Sent: 18/11/06, 07:30:48
Subject: Re: [HACKERS] Proposal: syntax of operation with tsearch's
configuration
Jeremy Drake wrote:
I am currently in the position that my hosting
Robert Treat wrote:
While I don't disagree that this is an important feature, the fact that it is
being designed with pgadmin specific backwards compatability (for example the
functions that rename core functions) leaves me dubious as to it being a more
general solution. Because of that I
Neil Conway wrote:
On Fri, 2006-10-20 at 22:59 +0200, Peter Eisentraut wrote:
Nothing except initdb should add objects in pg_catalog. AFAICS,
adminpack doesn't have any special requirements, so it should behave
like all other contrib modules.
Where are we on this? When this topic was last
901 - 1000 of 1699 matches
Mail list logo
