-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 backend
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/pgpatches
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.
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 anything
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
Bruce Momjian pgman@candle.pha.pa.us 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
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 yet
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
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 a
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
up
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 Solaris
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
Marko Kreen marko@l-t.ee 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
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us 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,
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!
On Tue, Jul 05, 2005 at 02:18:00PM -0400, Tom Lane wrote:
Marko Kreen marko@l-t.ee 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
Marko Kreen marko@l-t.ee 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
Marko Kreen marko@l-t.ee 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
On Tue, Jul 05, 2005 at 02:55:07PM -0400, Tom Lane wrote:
Marko Kreen marko@l-t.ee 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 marko@l-t.ee 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
Marko Kreen marko@l-t.ee 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
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 marko@l-t.ee 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
Marko Kreen marko@l-t.ee 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
On Tue, Jul 05, 2005 at 04:16:04PM -0400, Tom Lane wrote:
Marko Kreen marko@l-t.ee 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
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
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 try it out.
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
are now, which is
Marko Kreen marko@l-t.ee 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
Bruce Momjian pgman@candle.pha.pa.us 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
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 pgman@candle.pha.pa.us 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
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 function
Bruce Momjian pgman@candle.pha.pa.us 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
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
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us 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
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
CONTEXT: SQL
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 what
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 function foo
Bruce Momjian pgman@candle.pha.pa.us 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
41 matches
Mail list logo
