Mihai Criveti writes:
> So if this is a compiler bug, it certainly isn't an obvious one. I'll dig
> deeper to see how I can convince configure to use -qnooptimize.
Set CFLAGS in its environment. The default is set in src/template/aix
CFLAGS="-O2 -qmaxmem=16384 -qsrcmsg -qlonglong"
> When
The system and compiler are patched with the latest fix packs from IBM, and
the compiler version is the latest available.
The compiler is functional (eg: I was able to compile successfuly 64 bit
versions other software such as Apache 2.2.11, emacs 22.3, vim 7.2,
openssl-0.9.8j and so on, all with
Mihai Criveti writes:
> creating system views ... WARNING: could not dump unrecognized node type:
> 650
> WARNING: could not dump unrecognized node type: 650
> WARNING: could not dump unrecognized node type: 650
> WARNING: could not dump unrecognized node type: 650
> WARNING: could not dump u
Greg Stark writes:
> I don't understand what's wrong with the existing setup where DROP
> OIDS is a free operation.
It breaks things, in particular
http://archives.postgresql.org/pgsql-hackers/2008-11/msg00332.php
We could kluge around that particular problem, but the objection
I have to doing
I'm working on building the dependencies to run a build farm script on it,
may get better debugging results.
In the meantime, I haveanother build with:
./configure --enable-cassert --enable-debug
--with-includes=/opt/freeware/include --with-libraries=/opt/freeware/lib
--enable-thread-safety && gma
Please try configuring with --enable-debug --enable-cassert
Then if you don't get any more useful information you might need to try
initdb -d
cheers
andrew
Mihai Criveti wrote:
CC="xlC_r -q64" \
CXX="xlC_r -q64" \
AR="ar -X64" \
OBJECT_MODE=64 \
PATH=/usr/bin:/usr/vacpp/bin
./configure
mak
David Fetter wrote:
On Sun, Feb 08, 2009 at 11:51:22AM -0500, Tom Lane wrote:
Now, if you want to argue that we should get rid of SET WITHOUT OIDS
altogether,
+1 for removing it altogether. Row OIDs are and ugly wart :P
That might be true but I know of apps that use them. Hav
Hi Niranjan,
On Fri, Feb 6, 2009 at 10:17 PM, K, Niranjan (NSN - IN/Bangalore)
wrote:
>
> Hi,
>
>> * server log
>> * /sbydata/walreceiver_trace.out
>> * tcpdump -i lo -n tcp
>>
> Please refer attachments.
Please try the updated synch-rep, which probably fixes the problem, I hope.
If the same tro
CC="xlC_r -q64" \
CXX="xlC_r -q64" \
AR="ar -X64" \
OBJECT_MODE=64 \
PATH=/usr/bin:/usr/vacpp/bin
./configure
make
Make builds fine, but pg_regress: initdb fails. src/test/regress/log reads:
Running in noclean mode. Mistakes will not be cleaned up.
The files belonging to this database system wil
I don't understand what's wrong with the existing setup where DROP
OIDS is a free operation. And the space is cleaned up later when the
tuple is next written.
It seems exactly equivalent to how we handle DROP COLUMN where the
natt field of the tuple disagrees with the tuple descriptor and
On Sun, Feb 08, 2009 at 11:51:22AM -0500, Tom Lane wrote:
>
> Now, if you want to argue that we should get rid of SET WITHOUT OIDS
> altogether,
+1 for removing it altogether. Row OIDs are and ugly wart :P
Cheers,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter6
Peter Eisentraut wrote:
Notice that the thread originally called for lzma support, which is
completely at the opposite end of the spectrum of compression algorithms
in terms of space and time, compared to lzo. So it's not really clear
what the requirements are in the first place.
Instea
Bruce Momjian wrote:
Peter Eisentraut wrote:
I have recently fixed the configure script to recognize Python 3.0. But
note that building and running PL/Python with Python 3.0 does not
actually work. It looks like several symbols have been removed or
changed. It would be good if the Python pu
daveg wrote:
I think the context here is for pg_dump only and in that context a faster
compression library makes a lot of sense. I'd be happy to prepare a patch
if the license issue can be accomodated.
Some kind of performance data (space and time) would be required to
support any change in th
On Sun, Feb 8, 2009 at 11:51 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> Tom Lane wrote:
>>> The attached patch (which lacks doc changes or regression
>>> tests as yet) does that, and also adds the inverse SET WITH OIDS
>>> operation to do what you'd expect, ie, add an OID column if it isn't
Zdenek Kotala writes:
> Tom Lane pÃÅ¡e v ne 08. 02. 2009 v 11:51 -0500:
>> Now, if you want to argue that we should get rid of SET WITHOUT OIDS
>> altogether, I'm not sure I could dispute it. But if we have the
>> ability to do that ISTM we should offer the reverse too.
> By my opinion TABLES w
Tom Lane píše v ne 08. 02. 2009 v 11:51 -0500:
> Now, if you want to argue that we should get rid of SET WITHOUT OIDS
> altogether, I'm not sure I could dispute it. But if we have the
> ability to do that ISTM we should offer the reverse too.
By my opinion TABLES with OIDs is obsolete feature. I
Andrew Dunstan writes:
> Tom Lane wrote:
>> The attached patch (which lacks doc changes or regression
>> tests as yet) does that, and also adds the inverse SET WITH OIDS
>> operation to do what you'd expect, ie, add an OID column if it isn't
>> there already.
> Why would we add an operation to im
Tom Lane wrote:
The attached patch (which lacks doc changes or regression
tests as yet) does that, and also adds the inverse SET WITH OIDS
operation to do what you'd expect, ie, add an OID column if it isn't
there already.
Why would we add an operation to implement a deprecated feature? T
We have an open problem with CVS HEAD that ALTER TABLE SET WITHOUT OIDS
causes problems:
http://archives.postgresql.org/pgsql-hackers/2008-11/msg00332.php
I opined at the time that what we really have here is a table whose
tuples do not match its declared rowtype, and that the proper fix is
to mak
Martijn van Oosterhout wrote:
Why don't we just add an option to pg_dump --use-compress-program, just
like tar and then people can use their "compression algorithm of the
week" and we don't need to care about the licence or anything.
It's not like the case of TOAST where it actually needs to
Why don't we just add an option to pg_dump --use-compress-program, just
like tar and then people can use their "compression algorithm of the
week" and we don't need to care about the licence or anything.
Can't this be done already?
pg_dump -Z 0 | compression_binary >mydump
If -Z is unspecif
On 8 Feb 2009, at 02:49, Robert Haas wrote:
On Feb 7, 2009, at 4:53 PM, Bruce Momjian wrote:
we need to add this to the
"Features we do not want" section of our todo list.
"Proprietary compression algorithms, even with Postgresql-specific
license exceptions"?
Now that I would agr
On Sat, Feb 07, 2009 at 08:31:23PM -0800, David Fetter wrote:
> Considering that the entire project ships with a BSD license, which
> very specifically allows use of all or any tiniest part of it with
> (skipping some legalese) two restrictions: mention PGDG in the
> copyright list, and don't sue u
24 matches
Mail list logo
