> -Original Message-
> From: Christopher Kings-Lynne [mailto:[EMAIL PROTECTED]
> Sent: 05 July 2005 02:39
> To: Robert Treat
> Cc: Bruce Momjian; Dave Page; Tom Lane; Dawid Kuroczko;
> Andreas Pflug; PostgreSQL-patches; PostgreSQL-development
> Subject: Re: [HACKERS] [PATCHES] Dbsize b
On Tue, Jul 05, 2005 at 10:20:17AM +1000, Neil Conway wrote:
> Bruce Momjian wrote:
> >Your patch has been added to the PostgreSQL unapplied patches list
>
> That is not the latest version of Marko's patch.
Bruce got v3, thats indeed the latest.
Also, http://momjian.postgresql.org/cgi-bin/pgpatc
The latest timezone lib changes seem to have broken Windows and Cygwin
builds comprehensively. I assume that this checkin caused the problem:
http://archives.postgresql.org/pgsql-committers/2005-07/msg00155.php :
Restructure zic #define fprintf checks to use a NO_PGPORT macro instead.
Extra
On my Solaris 9/sparc box with OpenSSL 0.9.8-beta6, the pgcrypto
regression tests fail the 3des test. I haven't checked against
older versions of OpenSSL; I'll do so when I get a chance.
I haven't dug into the pgcrypto code yet -- is it doing anything
that might be platform-specific? Or is this
Michael Fuhr <[EMAIL PROTECTED]> writes:
> On my Solaris 9/sparc box with OpenSSL 0.9.8-beta6, the pgcrypto
> regression tests fail the 3des test. I haven't checked against
> older versions of OpenSSL; I'll do so when I get a chance.
> I haven't dug into the pgcrypto code yet -- is it doing anyth
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Alvaro Herrera wrote:
>> I see new warnings in the generation of plpgsql's scanner:
>>
>> /usr/bin/flex -Pplpgsql_base_yy
>> -o'/pg/source/00orig/src/pl/plpgsql/src/pl_scan.c'
>> /pg/source/00orig/src/pl/plpgsql/src/scan.l
>> /pg/source/00orig/src/pl
Bruce Momjian writes:
> That is a question I had in my mind. I added documentation that turning
> off fsync also disables full_page_writes, but we could decouple them and
> tell people to consider disableing full_pages_writes if they turn off
> fsync, basically suggesting they make the second cha
On Tue, Jul 05, 2005 at 08:40:08AM -0600, Michael Fuhr wrote:
> On my Solaris 9/sparc box with OpenSSL 0.9.8-beta6, the pgcrypto
> regression tests fail the 3des test. I haven't checked against
> older versions of OpenSSL; I'll do so when I get a chance.
>
> I haven't dug into the pgcrypto code y
On Tue, Jul 05, 2005 at 07:21:17PM +0300, Marko Kreen wrote:
>
> It is a bug in pgcrypto. I can only excuse it with my strong antipathy
> towards 3des.
>
> Could you test it with newer OpenSSL?
Looks good. After applying the patch, all pgcrypto regression tests
pass on my box running Solaris 9
Andrew Dunstan wrote:
>
> The latest timezone lib changes seem to have broken Windows and Cygwin
> builds comprehensively. I assume that this checkin caused the problem:
>
> http://archives.postgresql.org/pgsql-committers/2005-07/msg00155.php :
>
> Restructure zic #define fprintf checks to use
On Mon, Jul 04, 2005 at 05:58:27PM +0200, Peter Eisentraut wrote:
> Andrew Dunstan wrote:
> > I was also slightly dubious about it. However, we do still need to
> > solve the problem that the patch addressed. Buildfarm members
> > platypus and cuckoo are currently failing because dblink is picking
Michael Fuhr <[EMAIL PROTECTED]> writes:
> On Tue, Jul 05, 2005 at 07:21:17PM +0300, Marko Kreen wrote:
>> It is a bug in pgcrypto. I can only excuse it with my strong antipathy
>> towards 3des.
> Looks good. After applying the patch, all pgcrypto regression tests
> pass on my box running Solari
Jim C. Nasby wrote:
> > B: in-tree libraries that we might need (in case of ecpglib: libpq)
> > A: path to those in-tree libraries
>
> Is A even represented in the build at all right now? ISTM it's not,
Sure it is. How else would anything like psql and pg_dump find libpq?
--
Peter Eisentraut
ht
Marko Kreen writes:
> On Tue, Jul 05, 2005 at 08:40:08AM -0600, Michael Fuhr wrote:
>> On my Solaris 9/sparc box with OpenSSL 0.9.8-beta6, the pgcrypto
>> regression tests fail the 3des test. I haven't checked against
>> older versions of OpenSSL; I'll do so when I get a chance.
> It is a bug in
Tom Lane wrote:
> Bruce Momjian writes:
> > That is a question I had in my mind. I added documentation that turning
> > off fsync also disables full_page_writes, but we could decouple them and
> > tell people to consider disableing full_pages_writes if they turn off
> > fsync, basically suggestin
Tom Lane wrote:
Now that I look, the reason the buildfarm failed to find this is of
course that the pgcrypto Makefile is configured to never build or test
this code. Would it be reasonable to fix the makefile to follow the
toplevel --with-openssl choice?
Yes, please! good catch!
andre
On Tue, Jul 05, 2005 at 02:18:00PM -0400, Tom Lane wrote:
> Marko Kreen writes:
> > On Tue, Jul 05, 2005 at 08:40:08AM -0600, Michael Fuhr wrote:
> >> On my Solaris 9/sparc box with OpenSSL 0.9.8-beta6, the pgcrypto
> >> regression tests fail the 3des test. I haven't checked against
> >> older ve
Marko Kreen writes:
> I see 2 variants:
> 1) put @with_openssl@ and @with_zlib@ variables into
>contrib/pgcrypto/Makefile.in and let configure process it.
> 2) put them in some other makefile fragment under src/
>and let pgcrypto include it.
> First I did the simple thing and put them in
Marko Kreen writes:
> On Tue, Jul 05, 2005 at 02:55:07PM -0400, Tom Lane wrote:
>> Hm ... libpq manages to build code that requires openssl without
>> needing a generated Makefile, so why do we need it here?
> Now, looking more into it, it indeed does work.
> But it breaks pgcrypto build for USE_
On Tue, Jul 05, 2005 at 02:55:07PM -0400, Tom Lane wrote:
> Marko Kreen writes:
> > I see 2 variants:
>
> > 1) put @with_openssl@ and @with_zlib@ variables into
> >contrib/pgcrypto/Makefile.in and let configure process it.
> > 2) put them in some other makefile fragment under src/
> >and
On Tue, Jul 05, 2005 at 03:36:06PM -0400, Tom Lane wrote:
> Marko Kreen writes:
> > On Tue, Jul 05, 2005 at 02:55:07PM -0400, Tom Lane wrote:
> >> Hm ... libpq manages to build code that requires openssl without
> >> needing a generated Makefile, so why do we need it here?
>
> > Now, looking more
Marko Kreen writes:
> Oh, ofcourse I would not need to break it, if the interesting
> settings can be put into eg. src/Makefile.config (.in), and
> I include that one.
You mean Makefile.global.in, no? That seems fine to me.
> But that case would break if top_srcdir is not ../..
No it wouldn't.
I wrote:
> So either we code up some intelligence to put the "C" in the right
> position or we have to pass down "A B" and "D" separately from the
> main makefile.
The following patch might just do the former. Please try it out.
diff -ur ../cvs-pgsql/src/Makefile.shlib ./src/Makefile.shlib
---
On Tue, Jul 05, 2005 at 03:58:43PM -0400, Tom Lane wrote:
> Marko Kreen writes:
> > Oh, ofcourse I would not need to break it, if the interesting
> > settings can be put into eg. src/Makefile.config (.in), and
> > I include that one.
>
> You mean Makefile.global.in, no? That seems fine to me.
N
Marko Kreen writes:
> On Tue, Jul 05, 2005 at 03:58:43PM -0400, Tom Lane wrote:
>> You mean Makefile.global.in, no? That seems fine to me.
> No, thats the point - the PGXS include also includes
> Makefile.global, and including it twice does not work.
So? pgxs.mk includes Makefile.global before
On Tue, Jul 05, 2005 at 04:16:04PM -0400, Tom Lane wrote:
> Marko Kreen writes:
> > On Tue, Jul 05, 2005 at 03:58:43PM -0400, Tom Lane wrote:
> >> You mean Makefile.global.in, no? That seems fine to me.
>
> > No, thats the point - the PGXS include also includes
> > Makefile.global, and including
I can't believe I am the first one to respond to this :)
On 6/27/05, Simon Riggs wrote:
> On Mon, 2005-06-27 at 01:41 +0100, Simon Riggs wrote:
>>
>> The main purpose of this feature is to reduce access time against large
>> tables that have been split into partitions by using the PostgreSQL
>> in
On Tue, Jul 05, 2005 at 10:09:19PM +0200, Peter Eisentraut wrote:
> I wrote:
> > So either we code up some intelligence to put the "C" in the right
> > position or we have to pass down "A B" and "D" separately from the
> > main makefile.
>
> The following patch might just do the former. Please tr
Dave Page wrote:
> > >>You are into the cycle we were in. We discussed pg_object size (too
> > >>vague) and pg_index_size (needs pg_toast_size too, and maybe toast
> > >>indexes; too many functions).
> > >
> > > Yeah, I read those discussions, and think you were better
> > off then than you
> >
Marko Kreen writes:
> Ok Tom, you win. It is indeed possible to make it work, and the
> resulting makefile is even cleaner than before.
> Following patch thus autoconfigures pgcrypto. It drops the
> possibility to use libc's crypt, which was pointless.
Applied with a little extra hacking (compl
Bruce Momjian writes:
> If we go pg_table_size() and pg_relation_size(), which is object-only
> and which is heap + index + toast? I think ideally we want
> pg_relation_size to be the combined one, but then we have pg_table_size
> that works on indexes and toast too, and that is confusing, and we
This works on 7.4 and 8.0 but not in cvs head:
create function foo(pg_type) returns oid as 'select $1.oid' language sql;
ERROR: column "oid" not found in data type pg_type
CONTEXT: SQL function "foo"
Is this intentional, or did the no-oids-by-default changes cut too deep?
--
Andrew, Supernews
Tom Lane wrote:
> Bruce Momjian writes:
> > If we go pg_table_size() and pg_relation_size(), which is object-only
> > and which is heap + index + toast? I think ideally we want
> > pg_relation_size to be the combined one, but then we have pg_table_size
> > that works on indexes and toast too, and
Cygwin seems fixed, but now on my Windows box I get this:
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -fno-strict-aliasing
-I../../src/include -I./src/include/port/win32 -DEXEC_BACKEND
"-I../../src/include/port/win32" -DBUILDING_DLL -I. -DNO_PGPORT -c -o
zic.o zic.c
zic.c: In functio
Bruce Momjian writes:
> Tom Lane wrote:
>> I could live with that. Or "pg_total_relation_size".
> The problem with "total", to me, is that it already is the total size of
> the heap/index/toast. Complete has the idea of adding additional
> pieces, which I think fits best.
[ shrug ] I don't ca
Andrew - Supernews <[EMAIL PROTECTED]> writes:
> This works on 7.4 and 8.0 but not in cvs head:
> create function foo(pg_type) returns oid as 'select $1.oid' language sql;
> ERROR: column "oid" not found in data type pg_type
> CONTEXT: SQL function "foo"
> Is this intentional, or did the no-oids
OK, now we have a problem. :-(
While using native versions of libc functions rather than our pgport
enhanced versions is OK for zic, the use of symlink is a problem because
there is no native Win32 version.
Looking at zic.c::dolink, it calls symlink() if link() fails. I suppose
we could bring
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> I could live with that. Or "pg_total_relation_size".
>
> > The problem with "total", to me, is that it already is the total size of
> > the heap/index/toast. Complete has the idea of adding additional
> > pieces, which I think fit
On Tue, Jul 05, 2005 at 10:55:38PM -0400, Tom Lane wrote:
> Andrew - Supernews <[EMAIL PROTECTED]> writes:
> > This works on 7.4 and 8.0 but not in cvs head:
> > create function foo(pg_type) returns oid as 'select $1.oid' language sql;
> > ERROR: column "oid" not found in data type pg_type
> > CON
On Tue, Jul 05, 2005 at 09:22:37PM -0600, Michael Fuhr wrote:
>
> It fails for any system column -- weren't there some changes recently
> in how system columns are handled?
...or was that just discussion that never resulted in any changes?
I'm still digging through the archives trying to find wha
On 2005-07-06, Tom Lane <[EMAIL PROTECTED]> wrote:
> Andrew - Supernews <[EMAIL PROTECTED]> writes:
>> This works on 7.4 and 8.0 but not in cvs head:
>> create function foo(pg_type) returns oid as 'select $1.oid' language sql;
>> ERROR: column "oid" not found in data type pg_type
>> CONTEXT: SQL
Bruce Momjian writes:
> OK, now we have a problem. :-(
No kidding. I said to begin with that this plan to use target-specific
configuration knowledge to build a program executable by the host would
not work. I'm for reverting Peter's initial patch; maybe we can someday
find an answer, but this
42 matches
Mail list logo
