Re: [HACKERS] add server include files to default installation?
> This is from an extension module author's point of view. My module will > reference these two files only: > > Makefile.global > Makefile.shlib These files possibly include other makefiles. > I'm not the least interested in how these files are organized internally Sure. > If I have a "pg_config --makefiledir" that tells me where to find the > files, that should be all I need: > > makefiledir := $(shell pg_config --makefiledir) > include $(makefiledir)/Makefile.global > ... > Just trying to give you a bit more freedom to place your files :-) You do not understand how bad it is from the inside;-) In the current Makefile.global, you find things like: include $(top_...)/src/Makefile.port That is the makefile knows where it is expected to reside wrt the source tree, and use this information. In order to allow what you describe, I would have to fix this issue, that is rewrite somehow Makefile.global and other makefiles. Maybe I could do that, but I was trying hard to avoid it, as there may be some kind of portability issues. Thanks for you comment, -- Fabien Coelho - [EMAIL PROTECTED] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Call for 7.5 feature completion
Tatsuo Ishii wrote: At least in Japan PHP is much more popular than Python. If we have plpython in core, I see no reason we do not have plPHP in core at least from the "popularity" point of view. Well I don't know anywhere that PHP isn't more popular than Python. The question I think is a technical one. Python is a better "language" that PHP is. Perl is as well but that is a whole other argument. PHP is what I call the "Dumb Monkey" language. It isn't meant to be rude, but the reality is that almost any dumb monkey can code something in PHP. Python takes actual thought to produce something useful. Whether or not that is a bad thing is for another argument :) Sincerely, Joshua D. Drake -- Tatsuo Ishii ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL
Re: [HACKERS] Call for 7.5 feature completion
So, why tie it into the PostgreSQL source tree? Won't it be popular enough to live on its own, that it has to be distributed as part of the core? Honestly, I don't know if it would be popular enough on its own. Now the plPerlNG that Andrew and us are working, yes but plPHP? It is nifty, it is cool, it is very capable but it is still PHP. I think the point of having it in core is that the three most popular user space languages are: Python Perl PHP If those are covered within core under the pl* then we have all bases covered. I am not saying that it should be in core (although I definately think plPerlNG should be). This all started because it was suggested it could be :) J Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] pg_autovacuum seems to be a neat freak and cleans
On Tue, 2004-05-18 at 22:21, Brian Hirt wrote: > there might be another similar bug that was fixed in 7.4.2 This bug is fixed, but it didn't make in 7.4.2, it is in CVS (both 7.4 and HEAD). Please grab pg_autovacuum.c and .h from CVS, if that doesn't fix it please let me know. Thanks, Matthew ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] psql weirdness in HEAD
Christopher Kings-Lynne wrote: > I run psql and I get this: > > -bash-2.05b$ psql template1 > Welcome to psql 7.5devel, the PostgreSQL interactive terminal. > > Type: \copyright for distribution terms > \h for help with SQL commands > \? for help with psql commands > \g or terminate with semicolon to execute query > \q to quit > > could not stat "/sbin/psql": mcould not stat "/bin/psql": mcould not > stat "/usr/sbin/psql": mcould not stat "/usr/bin/psql": mcould not stat > "/usr/games/psql": mcould not stat "/usr/local/sbin/psql": mcould not > stat "/usr/local/bin/psql": mcould not stat "/usr/X11R6/bin/psql": > mcould not stat "/home/chriskl/bin/psql": mtemplate1=# > > I do have the tablespaces patch applied, but I can't see anything that > could have caused this. It seems more likely do be a relocatable > install bug... Maybe some leftover debug code? Just fixed. Thanks. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Call for 7.5 feature completion
Marc G. Fournier wrote: > On Mon, 17 May 2004, Alvaro Herrera Munoz wrote: > > > I have some confidence in that I will be able to deliver it maybe the last > > week of May. I can only hope, however, that it will not be rejected because > > it's presented too close to feature freeze. > > There is no such thing as "too close to feature freeze", nor has there > ever been in the past ... other then missing it altogether. Unless there > are some serious flaws in the implementation, submitting it on May 31st > would get it in ...it isn't expecting to be rock solid, bug free, that is > what the beta period is to work out ... > > What is expected, though, is that you won't disappear after its committed, > so that you can fix any bugs reported in a timely manner ... Not completely true. If a patch needs major rework or the implemention isn't acceptable, it might be rejected and have to wait --- it has happened before, and PITR might not make it because the April 1 patch wasn't an acceptable implementation. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Call for 7.5 feature completion
> On Tue, 18 May 2004, Joshua D. Drake wrote: > > > Actually plPHP doesn't require the PostgreSQL source tree... you would > > just have to modify the Make file to point to the right places. > > So, why tie it into the PostgreSQL source tree? Won't it be popular > enough to live on its own, that it has to be distributed as part of the > core? At least in Japan PHP is much more popular than Python. If we have plpython in core, I see no reason we do not have plPHP in core at least from the "popularity" point of view. -- Tatsuo Ishii ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Call for 7.5 feature completion
On Mon, 17 May 2004, Alvaro Herrera Munoz wrote: > I have some confidence in that I will be able to deliver it maybe the last > week of May. I can only hope, however, that it will not be rejected because > it's presented too close to feature freeze. There is no such thing as "too close to feature freeze", nor has there ever been in the past ... other then missing it altogether. Unless there are some serious flaws in the implementation, submitting it on May 31st would get it in ...it isn't expecting to be rock solid, bug free, that is what the beta period is to work out ... What is expected, though, is that you won't disappear after its committed, so that you can fix any bugs reported in a timely manner ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Clean-up callbacks for non-SR functions
James William Pye <[EMAIL PROTECTED]> writes: > I know I can use RegisterExprContextCallback and the RSI's econtext to > register a callback for SRFs, but this--or similar > functionality--does not appear to be available for non-SRFs. Hm? That functionality works for any function, whether it returns a set or not. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] [GENERAL] PgSQL 7.4.2 - NaN on Tru64 UNIX
Nikola Milutinovic <[EMAIL PROTECTED]> writes: > [ about NaN on Tru64 ] > This compiles on Tru64 4.0D (the compiler swallows it), but fails on > Tru64 UNIX 5.1B. Both basic CC and DTK Compaq CC break on that file > complaining on that constant evaluation. The best way to solve it is to > use system definition of "Infinity Constants": > ... > + #define NAN DBL_INFINITY Current CVS tip will probably fail with this, because we expect the platform to distinguish between NaN and Infinity. Could you retry your experiments with a recent snapshot and let us know what seems best now? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Call for 7.5 feature completion
On Tue, 18 May 2004, Joshua D. Drake wrote: > Actually plPHP doesn't require the PostgreSQL source tree... you would > just have to modify the Make file to point to the right places. So, why tie it into the PostgreSQL source tree? Won't it be popular enough to live on its own, that it has to be distributed as part of the core? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Call for 7.5 feature completion
On Tue, 18 May 2004, Heikki Linnakangas wrote: > I'd like to get the patch committed as soon as the 7.6 release cycle > begins, with whatever limitations it has at that time. The nice thing of this is that then you have a development cycle for others to help ... your patch lays down the "this is the direction, now add to it" ... I'd love to see 7.6 start off with a bunch of very large patches that can be then fleshed out over the course of the development cycle ... instead of a bunch of patches at the end of teh development cycle cause everyone is trying to squeeze things in ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] psql weirdness in HEAD
I get a similar failure running pg_dumpall and initdb as well. Chris Christopher Kings-Lynne wrote: I run psql and I get this: -bash-2.05b$ psql template1 Welcome to psql 7.5devel, the PostgreSQL interactive terminal. Type: \copyright for distribution terms \h for help with SQL commands \? for help with psql commands \g or terminate with semicolon to execute query \q to quit could not stat "/sbin/psql": mcould not stat "/bin/psql": mcould not stat "/usr/sbin/psql": mcould not stat "/usr/bin/psql": mcould not stat "/usr/games/psql": mcould not stat "/usr/local/sbin/psql": mcould not stat "/usr/local/bin/psql": mcould not stat "/usr/X11R6/bin/psql": mcould not stat "/home/chriskl/bin/psql": mtemplate1=# I do have the tablespaces patch applied, but I can't see anything that could have caused this. It seems more likely do be a relocatable install bug... Maybe some leftover debug code? Chris ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] psql weirdness in HEAD
I run psql and I get this: -bash-2.05b$ psql template1 Welcome to psql 7.5devel, the PostgreSQL interactive terminal. Type: \copyright for distribution terms \h for help with SQL commands \? for help with psql commands \g or terminate with semicolon to execute query \q to quit could not stat "/sbin/psql": mcould not stat "/bin/psql": mcould not stat "/usr/sbin/psql": mcould not stat "/usr/bin/psql": mcould not stat "/usr/games/psql": mcould not stat "/usr/local/sbin/psql": mcould not stat "/usr/local/bin/psql": mcould not stat "/usr/X11R6/bin/psql": mcould not stat "/home/chriskl/bin/psql": mtemplate1=# I do have the tablespaces patch applied, but I can't see anything that could have caused this. It seems more likely do be a relocatable install bug... Maybe some leftover debug code? Chris ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Call for 7.5 feature completion
On Tuesday 18 May 2004 21:58, Joshua D. Drake wrote: > > So you then have to build PHP twice, in an RPM build environment. You > > mean I can't just have the headers installed to build plPHP? So, follow > > the > No you need to make sure that PHP is available as a shared lib. Which requires you to build PHP. PHP is only going to get built once; do you build with or without PostgreSQL client support? As an RPM builder, you cannot build it one way, then rebuild it again another way. It's not self-hosting at that point. > > Try building the RPMs for PHP plus PostgreSQL and plPHP, then tell me how > > you solved the circular dependency. > Actually plPHP doesn't require the PostgreSQL source tree... you would > just have to modify the Make file to point to the right places. Then it can easily be a standalone project, and the issues go away. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] pg_autovacuum seems to be a neat freak and cleans way too much
there might be another similar bug that was fixed in 7.4.2
i just doubled checked the 7.4.2 tarball, and it does have this problem.
you might want to double check to see if it's fixed in 7.4.3, or i can
grab cvs and check it if you like.
On May 18, 2004, at 8:06 PM, Bruce Momjian wrote:
I think we already fixed that in 7.4.2. We also have a few bugs still
in 7.4.2 and we need to get those fixed soon and release 7.4.3.
---
Brian Hirt wrote:
I'm following up on my own email and cross posting to hackers, because
there is a bug that needs fixed. I spent some more time digging into
this, and I found the cause of the problem.
reltuples in pg_class is defined as a real, reltuples in
pg_autovacuum
is defined as an int. the query used to get reltuples returns
scientific notation for my larg tables, '4.06927e+06' for the one i
mention below.pg_autovacuum happily converts that to a '4' by
doing
atoi('4.06927e+06'), which is why it's all fubar for my large tables
with over a million tuples.
my real quick hack of changing the define in pg_autovacuum.h to cast
reltuples to ::int4 makes it work
line: 37
#define TABLE_STATS_QUERY "select
a.oid,a.relname,a.relnamespace,a.relpages,a.relisshared,a.reltuples::
int4,b.schemaname,b.n_tup_ins,b.n_tup_upd,b.n_tup_del from pg_class a,
pg_stat_all_tables b where a.oid=b.relid and a
.relkind = 'r'"
#define PAGES_QUERY "select oid,reltuples::int4,relpages from pg_class
where oid=%i"
however, i think a better fix would be to change the autovacuum to use
a double instead of an int. if it's going to stay at int, it should
probably be increased to long and the casts changed to ::int8
any suggestions on how best way to fix?
i'll supply a patch once the approach is agreed upon and the problem
has been verified.
best regards,
--brian
On May 18, 2004, at 7:37 PM, Brian Hirt wrote:
I've having a strange issue with pg_autovacuum. I have a table with
about 4 million rows in 20,000 pages. autovacuum likes to vacuum
and/or analyze it every 45 minutes or so, but it probably doesn't
have more that a few hundred rows changed every few hours. when i
run autovacuum with -d3 it says
[2004-05-18 07:04:26 PM] table name:
basement_nightly."public"."search_words4"
[2004-05-18 07:04:26 PM] relid: 396238832; relisshared: 0
[2004-05-18 07:04:26 PM] reltuples: 4; relpages: 20013
[2004-05-18 07:04:26 PM] curr_analyze_count: 0;
cur_delete_count: 0
[2004-05-18 07:04:26 PM] ins_at_last_analyze: 0;
del_at_last_vacuum: 0
[2004-05-18 07:04:26 PM] insert_threshold:504;
delete_threshold1008
reltuples: 4 seems wrong. I would expect a table with 4m rows and
20k
pages to have more than 4 tuples. I think this is why the insert
threshhold is all messed up -- which is why it gets analyzed way too
frequently.
this happens with other big tables too. the autovacuum is from
7.4.2, some information is below.
output from vacuum:
basement=# vacuum ANALYZE verbose search_words4;
INFO: vacuuming "public.search_words4"
INFO: index "search_words4_data_id" now contains 4069268 row
versions
in 15978 pages
DETAIL: 479 index row versions were removed.
1 index pages have been deleted, 0 are currently reusable.
CPU 0.42s/0.70u sec elapsed 29.48 sec.
INFO: index "search_words4_pkey" now contains 4069268 row versions
in
17576 pages
DETAIL: 479 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.77s/0.74u sec elapsed 150.19 sec.
INFO: "search_words4": removed 479 row versions in 6 pages
DETAIL: CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO: "search_words4": found 479 removable, 4069268 nonremovable row
versions in 19950 pages
DETAIL: 0 dead row versions cannot be removed yet.
There were 0 unused item pointers.
0 pages are entirely empty.
CPU 1.30s/1.61u sec elapsed 179.96 sec.
INFO: analyzing "public.search_words4"
INFO: "search_words4": 19950 pages, 3000 rows sampled, 4069800
estimated total rows
VACUUM
basement=#
here's the frequency
[2004-05-18 12:12:54 PM] Performing: ANALYZE "public"."search_words4"
[2004-05-18 01:59:13 PM] Performing: ANALYZE "public"."search_words4"
[2004-05-18 02:05:36 PM] Performing: ANALYZE "public"."search_words4"
[2004-05-18 02:29:25 PM] Performing: VACUUM ANALYZE
"public"."search_words4"
[2004-05-18 02:46:09 PM] Performing: ANALYZE "public"."search_words4"
[2004-05-18 03:39:31 PM] Performing: ANALYZE "public"."search_words4"
[2004-05-18 05:20:45 PM] Performing: ANALYZE "public"."search_words4"
[2004-05-18 06:08:03 PM] Performing: VACUUM ANALYZE
"public"."search_words4"
[2004-05-18 06:18:34 PM] Performing: ANALYZE "public"."search_words4"
[2004-05-18 07:34:27 PM] Performing: ANALYZE "public"."search_words4"
[2004-05-18 07:43:18 PM] Performing: ANALYZE "public"."search_words4"
---(end of
broadcast)---
TIP 6: Have you searched our list archives?
Re: [HACKERS] pg_autovacuum seems to be a neat freak and cleans way
I think we already fixed that in 7.4.2. We also have a few bugs still
in 7.4.2 and we need to get those fixed soon and release 7.4.3.
---
Brian Hirt wrote:
> I'm following up on my own email and cross posting to hackers, because
> there is a bug that needs fixed. I spent some more time digging into
> this, and I found the cause of the problem.
>
> reltuples in pg_class is defined as a real, reltuples in pg_autovacuum
> is defined as an int. the query used to get reltuples returns
> scientific notation for my larg tables, '4.06927e+06' for the one i
> mention below.pg_autovacuum happily converts that to a '4' by doing
> atoi('4.06927e+06'), which is why it's all fubar for my large tables
> with over a million tuples.
>
> my real quick hack of changing the define in pg_autovacuum.h to cast
> reltuples to ::int4 makes it work
>
> line: 37
> #define TABLE_STATS_QUERY "select
> a.oid,a.relname,a.relnamespace,a.relpages,a.relisshared,a.reltuples::
> int4,b.schemaname,b.n_tup_ins,b.n_tup_upd,b.n_tup_del from pg_class a,
> pg_stat_all_tables b where a.oid=b.relid and a
> .relkind = 'r'"
>
> #define PAGES_QUERY "select oid,reltuples::int4,relpages from pg_class
> where oid=%i"
>
> however, i think a better fix would be to change the autovacuum to use
> a double instead of an int. if it's going to stay at int, it should
> probably be increased to long and the casts changed to ::int8
>
> any suggestions on how best way to fix?
>
> i'll supply a patch once the approach is agreed upon and the problem
> has been verified.
>
>
> best regards,
>
> --brian
>
> On May 18, 2004, at 7:37 PM, Brian Hirt wrote:
>
> > I've having a strange issue with pg_autovacuum. I have a table with
> > about 4 million rows in 20,000 pages. autovacuum likes to vacuum
> > and/or analyze it every 45 minutes or so, but it probably doesn't
> > have more that a few hundred rows changed every few hours. when i
> > run autovacuum with -d3 it says
> >
> > [2004-05-18 07:04:26 PM] table name:
> > basement_nightly."public"."search_words4"
> > [2004-05-18 07:04:26 PM] relid: 396238832; relisshared: 0
> > [2004-05-18 07:04:26 PM] reltuples: 4; relpages: 20013
> > [2004-05-18 07:04:26 PM] curr_analyze_count: 0;
> > cur_delete_count: 0
> > [2004-05-18 07:04:26 PM] ins_at_last_analyze: 0;
> > del_at_last_vacuum: 0
> > [2004-05-18 07:04:26 PM] insert_threshold:504;
> > delete_threshold1008
> >
> > reltuples: 4 seems wrong. I would expect a table with 4m rows and 20k
> > pages to have more than 4 tuples. I think this is why the insert
> > threshhold is all messed up -- which is why it gets analyzed way too
> > frequently.
> >
> > this happens with other big tables too. the autovacuum is from
> > 7.4.2, some information is below.
> >
> >
> > output from vacuum:
> >
> > basement=# vacuum ANALYZE verbose search_words4;
> > INFO: vacuuming "public.search_words4"
> > INFO: index "search_words4_data_id" now contains 4069268 row versions
> > in 15978 pages
> > DETAIL: 479 index row versions were removed.
> > 1 index pages have been deleted, 0 are currently reusable.
> > CPU 0.42s/0.70u sec elapsed 29.48 sec.
> > INFO: index "search_words4_pkey" now contains 4069268 row versions in
> > 17576 pages
> > DETAIL: 479 index row versions were removed.
> > 0 index pages have been deleted, 0 are currently reusable.
> > CPU 0.77s/0.74u sec elapsed 150.19 sec.
> > INFO: "search_words4": removed 479 row versions in 6 pages
> > DETAIL: CPU 0.00s/0.00u sec elapsed 0.00 sec.
> > INFO: "search_words4": found 479 removable, 4069268 nonremovable row
> > versions in 19950 pages
> > DETAIL: 0 dead row versions cannot be removed yet.
> > There were 0 unused item pointers.
> > 0 pages are entirely empty.
> > CPU 1.30s/1.61u sec elapsed 179.96 sec.
> > INFO: analyzing "public.search_words4"
> > INFO: "search_words4": 19950 pages, 3000 rows sampled, 4069800
> > estimated total rows
> > VACUUM
> > basement=#
> >
> >
> >
> > here's the frequency
> > [2004-05-18 12:12:54 PM] Performing: ANALYZE "public"."search_words4"
> > [2004-05-18 01:59:13 PM] Performing: ANALYZE "public"."search_words4"
> > [2004-05-18 02:05:36 PM] Performing: ANALYZE "public"."search_words4"
> > [2004-05-18 02:29:25 PM] Performing: VACUUM ANALYZE
> > "public"."search_words4"
> > [2004-05-18 02:46:09 PM] Performing: ANALYZE "public"."search_words4"
> > [2004-05-18 03:39:31 PM] Performing: ANALYZE "public"."search_words4"
> > [2004-05-18 05:20:45 PM] Performing: ANALYZE "public"."search_words4"
> > [2004-05-18 06:08:03 PM] Performing: VACUUM ANALYZE
> > "public"."search_words4"
> > [2004-05-18 06:18:34 PM] Performing: ANALYZE "public"."search_words4"
> > [2004-05-18 07:34:27 PM] Performing: ANALYZE "public"."search_words4"
> > [2004-05-18 07:43:18 PM] Performing: ANALYZE "public"."search_w
Re: [HACKERS] Call for 7.5 feature completion
So you then have to build PHP twice, in an RPM build environment. You mean I can't just have the headers installed to build plPHP? So, follow the No you need to make sure that PHP is available as a shared lib. 1.) Build PostgreSQL 2.) Build PHP (with PostgreSQL client support) 3.) Build plPHP (with PostgreSQL SPI support, or maybe even PostgreSQL client support for cross database queries? :-)) Right. Try building the RPMs for PHP plus PostgreSQL and plPHP, then tell me how you solved the circular dependency. Actually plPHP doesn't require the PostgreSQL source tree... you would just have to modify the Make file to point to the right places. J ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] pg_autovacuum seems to be a neat freak and cleans way too much
I'm following up on my own email and cross posting to hackers, because
there is a bug that needs fixed. I spent some more time digging into
this, and I found the cause of the problem.
reltuples in pg_class is defined as a real, reltuples in pg_autovacuum
is defined as an int. the query used to get reltuples returns
scientific notation for my larg tables, '4.06927e+06' for the one i
mention below.pg_autovacuum happily converts that to a '4' by doing
atoi('4.06927e+06'), which is why it's all fubar for my large tables
with over a million tuples.
my real quick hack of changing the define in pg_autovacuum.h to cast
reltuples to ::int4 makes it work
line: 37
#define TABLE_STATS_QUERY "select
a.oid,a.relname,a.relnamespace,a.relpages,a.relisshared,a.reltuples::
int4,b.schemaname,b.n_tup_ins,b.n_tup_upd,b.n_tup_del from pg_class a,
pg_stat_all_tables b where a.oid=b.relid and a
.relkind = 'r'"
#define PAGES_QUERY "select oid,reltuples::int4,relpages from pg_class
where oid=%i"
however, i think a better fix would be to change the autovacuum to use
a double instead of an int. if it's going to stay at int, it should
probably be increased to long and the casts changed to ::int8
any suggestions on how best way to fix?
i'll supply a patch once the approach is agreed upon and the problem
has been verified.
best regards,
--brian
On May 18, 2004, at 7:37 PM, Brian Hirt wrote:
I've having a strange issue with pg_autovacuum. I have a table with
about 4 million rows in 20,000 pages. autovacuum likes to vacuum
and/or analyze it every 45 minutes or so, but it probably doesn't
have more that a few hundred rows changed every few hours. when i
run autovacuum with -d3 it says
[2004-05-18 07:04:26 PM] table name:
basement_nightly."public"."search_words4"
[2004-05-18 07:04:26 PM] relid: 396238832; relisshared: 0
[2004-05-18 07:04:26 PM] reltuples: 4; relpages: 20013
[2004-05-18 07:04:26 PM] curr_analyze_count: 0;
cur_delete_count: 0
[2004-05-18 07:04:26 PM] ins_at_last_analyze: 0;
del_at_last_vacuum: 0
[2004-05-18 07:04:26 PM] insert_threshold:504;
delete_threshold1008
reltuples: 4 seems wrong. I would expect a table with 4m rows and 20k
pages to have more than 4 tuples. I think this is why the insert
threshhold is all messed up -- which is why it gets analyzed way too
frequently.
this happens with other big tables too. the autovacuum is from
7.4.2, some information is below.
output from vacuum:
basement=# vacuum ANALYZE verbose search_words4;
INFO: vacuuming "public.search_words4"
INFO: index "search_words4_data_id" now contains 4069268 row versions
in 15978 pages
DETAIL: 479 index row versions were removed.
1 index pages have been deleted, 0 are currently reusable.
CPU 0.42s/0.70u sec elapsed 29.48 sec.
INFO: index "search_words4_pkey" now contains 4069268 row versions in
17576 pages
DETAIL: 479 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.77s/0.74u sec elapsed 150.19 sec.
INFO: "search_words4": removed 479 row versions in 6 pages
DETAIL: CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO: "search_words4": found 479 removable, 4069268 nonremovable row
versions in 19950 pages
DETAIL: 0 dead row versions cannot be removed yet.
There were 0 unused item pointers.
0 pages are entirely empty.
CPU 1.30s/1.61u sec elapsed 179.96 sec.
INFO: analyzing "public.search_words4"
INFO: "search_words4": 19950 pages, 3000 rows sampled, 4069800
estimated total rows
VACUUM
basement=#
here's the frequency
[2004-05-18 12:12:54 PM] Performing: ANALYZE "public"."search_words4"
[2004-05-18 01:59:13 PM] Performing: ANALYZE "public"."search_words4"
[2004-05-18 02:05:36 PM] Performing: ANALYZE "public"."search_words4"
[2004-05-18 02:29:25 PM] Performing: VACUUM ANALYZE
"public"."search_words4"
[2004-05-18 02:46:09 PM] Performing: ANALYZE "public"."search_words4"
[2004-05-18 03:39:31 PM] Performing: ANALYZE "public"."search_words4"
[2004-05-18 05:20:45 PM] Performing: ANALYZE "public"."search_words4"
[2004-05-18 06:08:03 PM] Performing: VACUUM ANALYZE
"public"."search_words4"
[2004-05-18 06:18:34 PM] Performing: ANALYZE "public"."search_words4"
[2004-05-18 07:34:27 PM] Performing: ANALYZE "public"."search_words4"
[2004-05-18 07:43:18 PM] Performing: ANALYZE "public"."search_words4"
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] Call for 7.5 feature completion
On Tuesday 18 May 2004 17:33, Joshua D. Drake wrote: > > But most binary packages do, and they are the ones I'm talking about. > > And surely you do not advocate that, in order to build PL/PHP, the > > packagers instead disable the client side support in PHP? > Of course not, but I still don't see your point. plPHP doesn't need > PHP+PostgreSQL support. Nor does PHP+PostgreSQL conflict with using > plPHP... > PHP doesn't even need to be installed for plPHP to work... You just > need the source tree for building. So you then have to build PHP twice, in an RPM build environment. You mean I can't just have the headers installed to build plPHP? So, follow the sequence of the RPM building events: 1.) Build PHP without PostgreSQL client support. 2.) Build PostgreSQL 3.) Build plPHP 4.) Build PHP with PostgreSQL client support. The Perl situation is totally different, since the Perl client is not part of the Perl source tree. The 4-step I mention above would never be followed by any distributions, who would probably just not build plPHP to keep from having the circular dependency. See, in the RPM build environment for self-hosting distributions, I would have to pull in the entire PHP source distribution during the PostgreSQL build. Keeping that synchronized with the PHP version that is the main one distributed would be a major pain. Better would be getting plPHP so that it doesn't need the PostgreSQL source tree, but just needs the development headers (with server-side) installed. Then there is no circular build dependency. Then I just: 1.) Build PostgreSQL 2.) Build PHP (with PostgreSQL client support) 3.) Build plPHP (with PostgreSQL SPI support, or maybe even PostgreSQL client support for cross database queries? :-)) Try building the RPMs for PHP plus PostgreSQL and plPHP, then tell me how you solved the circular dependency. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Call for 7.5 feature completion
Greg Copeland writes: > My primary fear about delivering Win32 with all of these other great > features is that, IMO, there is a higher level of risk associated with > these advanced features. At the same time, this will be the > first trial for many Win32 users. Should there be some problems, in general, > or worse, specific to Win32 users as it relates to these new features, it > could cost some serious Win32/PostgreSQL community points. A troubled > release which is experienced by Win32 users is going to be a > battle cry for MySQL. Just thought I'd jump in here with my $0.02. It was always my expectation that the first Win32 release, regardless of the features which accompanied it, would be clearly advertised as not for production (some here might suggest that simply mentioning Win32 and "not for production" in the same sentence is repeating myself, but I'm not going to be quite so cynical). It won't stop people going ahead and doing it regardless, but it buys us some press insurance. I'm confident that the Win32 port will be solid, and will go a long way in boosting PostgreSQLs popularity. That said, I simply don't think it isn't reasonable to expect that it'll go out the door with all quirks nailed the very first time, and we ought to be honest and up-front about these expectations. Cheers, Claudio --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see http://www.memetrics.com/emailpolicy.html";>http://www.memetrics.com/em ailpolicy.html ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] bitwise and/or aggregate functions?
Tom Lane wrote: > Neil Conway <[EMAIL PROTECTED]> writes: > > Fabien COELHO wrote: > >> Neil - can you check your SQL2003 copy to see if it mentions standard > >> aggregates on bit types? > > > I couldn't see any mention of any aggregates specific to the bit types, > > There certainly are none, since in fact SQL2003 removes the BIT types > entirely. See Annex E: > > 2) ISO/IEC 9075-2:1999 defined data types called BIT and BIT VARYING. >These data types have been deleted from this edition of ISO/IEC 9075. Understand. To me, allowing bitwise and boolean aggregates on a column seemed like a natural capability we should have. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Call for 7.5 feature completion
Seriously though, we all have the roles that we play. I don't think redirecting specific resources to other resources will help beyond slowing up the original resources. And now Neil's on holidays :) Perhaps we need more committers. The deluge of patches is starting to strain the major developers I think? Chris ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Call for 7.5 feature completion
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > What can be done? Well, money from Fujitsu and other companies > (Afilias/Sloney, Command Prompt/ecpg-plPHP), is allowing us to hit > some of these bigger items, so hopefully that will move us forward > in these complex areas. I am not sure what could have been done to > push some of these projects along faster. Perhaps some more public cajoling of the masses into helping out would be good. Not just development but testing. Occasional posts on general asking people to help test Win32 and PITR for example, or a prominent link on the main page asking people to try out the latest Win32. It may not be "beta-ready" yet, but it surely could not hurt to have people start testing as soon as possible. I'm also sure that there is probably some more development talent available out there that could help in some of these bigger items, but I've not seen a lot of people asking for help or suggesting ways that people could help. I realize that some of this items are large and complex, but there is always /something/ that people can do, even if it documentating new features, or even documenting how to understand the new feature from a developer's perspective. - -- Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200405182046 -BEGIN PGP SIGNATURE- iD8DBQFAqq6GvJuQZxSWSsgRAuruAKCkzWbtYcfu9DR+f4JUHKPWjaPiswCg/Vcf ZGLywaE2OOgr3Mk+Kua1fUA= =vqHP -END PGP SIGNATURE- ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] bitwise and/or aggregate functions?
Neil Conway <[EMAIL PROTECTED]> writes: > Fabien COELHO wrote: >> Neil - can you check your SQL2003 copy to see if it mentions standard >> aggregates on bit types? > I couldn't see any mention of any aggregates specific to the bit types, There certainly are none, since in fact SQL2003 removes the BIT types entirely. See Annex E: 2) ISO/IEC 9075-2:1999 defined data types called BIT and BIT VARYING. These data types have been deleted from this edition of ISO/IEC 9075. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Fixed directory locations in installs
Peter Eisentraut wrote: > Tom Lane wrote: > > > What use could printing the relative path possibly have? > > > > Debugging. If I can't see it, I *know* I'm going to wish I could. > > Well, you can just look inside, it's not that big. Supporting extra > options might make the script twice as big and thus make it harder to > just look at the whole thing. OK, this is a followup from Peter on the pg_config issue. We only do a relative path if they used the defaults and put it all under a single directory so there is probably little need for a pg_config addition. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Fixed directory locations in installs
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Tom Lane wrote: > >> I guess what you are saying is we should have a configure-time option to > >> address configured directories via relative paths from the executable's > >> directory, rather than absolute paths? Seems reasonable ... > > > Yep. In fact, why would we not use that by default? > > Because it'll be slower. Instead of > /usr/local/pgsql/lib > we'd be using something like > /usr/local/pgsql/bin/../lib > which is not too bad here but would get worse if the directories are not > so close. > > But perhaps we can arrange for the path to be simplified down to an > absolute form when it's constructed at backend startup? You'd need a > routine anyway to combine the bindir path (determined by FindExec) with > the relative path provided by configure, so maybe this routine could be > smart about leading ../ in the configure path. > > We'd also need to give some thought to pg_config output. I think I > would like to be able to see the relative path computed by configure > as well as the effective actual path ... maybe a switch to specify which > way to print it? Does this pg_config addition need to be done? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] question about information_schema
Dave Cramer <[EMAIL PROTECTED]> writes: > While I'm asking how can I find all of the user defined types, assuming > that the user is the owner of the cluster. I see that pg_dump can do > this ? IIRC, what pg_dump actually does is look for types that are not in the pg_catalog schema. Plus you probably want to exclude composite types other than "standalone" ones (ie, all those whose associated pg_class entry has a relkind other than COMPOSITE_TYPE). regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] XactIsoLevel handling
Heikki Linnakangas <[EMAIL PROTECTED]> writes: > Why is the isLocal-parameter false? Couldn't it be true as well? It works > as it is, since the XactIsoLevel variable is reset to default value in > StartTransaction anyway, but it looks silly to me to define the variable > as a session variable when in fact it acts like a local one. Perhaps it could be true instead, but I see no point in invoking the extra overhead of the local-variable mechanism given that this variable is special-cased anyway. > I bumped into this because my current 2PC doesn't allow you to set session > variables. Seems like the problem is right there, not with XactIsoLevel ... you cannot seriously claim that that is an acceptable restriction. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Relocatable installs
Bruce Momjian wrote: Peter Eisentraut wrote: Jan Wieck wrote: > Boy, nobody was suggesting 100% static linking. What kind of madness > are you getting into if you link libpq.a into psql? There is > something between all or nothing, isn't there? It's not going to be only psql and libpq. The next thing is, someone wants to have a relocatable libpqxx, or a relocatable PHP, or a relocatable MyCoolReplicationSystem. Before you know it, half the world has the other half of the world statically linked. This can't be the solution. So your opinion is that we need to just require some user configuration changes to find the shared libs, right? Peter is mixing issues here. How another application finds the right libpq.so, libpqxx.so or whatever interface lib after someone moved the PostgreSQL lib directory somewhere else has absolutely nothing to do with how we make sure that our binary utilities like initdb, psql and so forth are protected against using the wrong one in a multi-version relocatable environment. And that some platforms support relative rpath is nice handwaving, but it doesn't get us anywhere. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Call for 7.5 feature completion
Peter Eisentraut wrote: Joshua D. Drake wrote: Of course not, but I still don't see your point. plPHP doesn't need PHP+PostgreSQL support. Nor does PHP+PostgreSQL conflict with using plPHP... PHP doesn't even need to be installed for plPHP to work... You just need the source tree for building. O.k. now I get it.. Basically you are saying that in order to build plPHP you need PHP and PostgreSQL (regardless if they know about each other). So in order to build plPHP you need to build PostgreSQL, then PHP, then plPHP... versus just Postgresql+plPHP... However plPHP is a configure option (when patched)... Thus if they choose with-php then they would (presumably) know what they were getting into. That makes sense. Sincerely, Joshua D. Drake I don't talk about manual build processes, I talk about (semi-)automatic package builds. The PHP package has a build dependency on PostgreSQL, because it needs libpq. So PostgreSQL needs to be built and installed before PHP can be built. But then, if PL/PHP were to be integrated into PostgreSQL, PHP needs to be installed first, so the PostgreSQL+PL/PHP build can get at the PHP headers files and whatever else it needs. So you can neither build PHP first nor build PostgreSQL first. So building PL/PHP doesn't need a PHP with PostgreSQL support. But no one is going to build two versions of PHP packages just so PostgreSQL can build. That is a mess we can happily avoid. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] add server include files to default installation?
Fabien COELHO wrote: Any idea? The best I have would be to create a "src" subdir in the installation, so that top_builddir could be set to ".../include/postgresql/config" and everything would work from that point of view. This is from an extension module author's point of view. My module will reference these two files only: Makefile.global Makefile.shlib I'm not the least interested in how these files are organized internally or where they are placed in reference to what they contain. I don't care where the include files, config files, or other files are located, as long as these two files will set my flags accordingly. I think it's important to recognize this separation of concern. Extension modules should not need to worry about anything but where to find these two files. If I have a "pg_config --makefiledir" that tells me where to find the files, that should be all I need: makefiledir := $(shell pg_config --makefiledir) include $(makefiledir)/Makefile.global ... include $(makefiledir)/Makefile.shlib If I go in and parse the makefiles to dig out information or do something equally horrible, I'm either doing something wrong or something is missing in the "contract" between the backend and the extension module and should be rectified there. The contract, the way I see it, is constituted by the two files. Just trying to give you a bit more freedom to place your files :-) Kind regards, Thomas Hallgren ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Why new features only in magior releases ?
Gaetano Mendola wrote: Currently some changes are back ported to old branches ( BTW, why not to switch to use "subversion"? ) so I don't think this actualy a big issue The only changes that are presently backported are bug fixes that the committing developer feels confident will not cause a regression (for this reason, it is common practice to commit a simplified version of a change to the stable release series, and a more complete rewrite to -devel). It would require significantly more work to backport larger changes -- both due to code drift in the development branch, and the likelihood that larger changes that introduce new features will require a lot more testing than small changes that fix critical, localized bugs. (Of course, one option for users who want new features in a stable release series is to hire a company to backport them for you. It is already common practice for some companies to support PostgreSQL releases for longer than the development group is prepared to do.) As for using SVN, that's been suggested before (there was a long thread on it recently). I wouldn't object, although (a) I don't see the rush, CVS works fine for us AFAIK (b) arch might be worth considering as an alternative. -Neil ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Call for 7.5 feature completion
Joshua D. Drake wrote: > Of course not, but I still don't see your point. plPHP doesn't need > PHP+PostgreSQL support. Nor does PHP+PostgreSQL conflict with using > plPHP... > > PHP doesn't even need to be installed for plPHP to work... You just > need the source tree for building. I don't talk about manual build processes, I talk about (semi-)automatic package builds. The PHP package has a build dependency on PostgreSQL, because it needs libpq. So PostgreSQL needs to be built and installed before PHP can be built. But then, if PL/PHP were to be integrated into PostgreSQL, PHP needs to be installed first, so the PostgreSQL+PL/PHP build can get at the PHP headers files and whatever else it needs. So you can neither build PHP first nor build PostgreSQL first. So building PL/PHP doesn't need a PHP with PostgreSQL support. But no one is going to build two versions of PHP packages just so PostgreSQL can build. That is a mess we can happily avoid. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Relocatable installs
Peter Eisentraut wrote: > Jan Wieck wrote: > > Boy, nobody was suggesting 100% static linking. What kind of madness > > are you getting into if you link libpq.a into psql? There is > > something between all or nothing, isn't there? > > It's not going to be only psql and libpq. The next thing is, someone > wants to have a relocatable libpqxx, or a relocatable PHP, or a > relocatable MyCoolReplicationSystem. Before you know it, half the > world has the other half of the world statically linked. This can't be > the solution. So your opinion is that we need to just require some user configuration changes to find the shared libs, right? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Relocatable installs
Jan Wieck wrote: > Boy, nobody was suggesting 100% static linking. What kind of madness > are you getting into if you link libpq.a into psql? There is > something between all or nothing, isn't there? It's not going to be only psql and libpq. The next thing is, someone wants to have a relocatable libpqxx, or a relocatable PHP, or a relocatable MyCoolReplicationSystem. Before you know it, half the world has the other half of the world statically linked. This can't be the solution. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Relocatable installs
Peter Eisentraut wrote: > Bruce Momjian wrote: > > Peter Eisentraut wrote: > > > Bruce Momjian wrote: > > > > We already have --disable-rpath. Seems we would just need > > > > something to use the *.a files. > > > > > > I think it is perfectly sufficient to say that if you want a > > > relocatable install, don't use rpath. Static linking will lead to > > > all other kinds of madness. > > > > OK, I added some more documentation about how to make relocatable > > installs. > > The shared library path issues are explained in detail later. You > should refer there rather than listing only a few ideas that may or may > not work. We can't assume that people will have an enlightenment at > the mere appearance of the word LD_LIBRARY_PATH. Thanks. New text: For relocatable installs, you might want to use configure's --disable-rpath option. Also, you will need to tell the operating system how to find the shared libraries. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Relocatable installs
Bruce Momjian wrote: > Peter Eisentraut wrote: > > Bruce Momjian wrote: > > > We already have --disable-rpath. Seems we would just need > > > something to use the *.a files. > > > > I think it is perfectly sufficient to say that if you want a > > relocatable install, don't use rpath. Static linking will lead to > > all other kinds of madness. > > OK, I added some more documentation about how to make relocatable > installs. The shared library path issues are explained in detail later. You should refer there rather than listing only a few ideas that may or may not work. We can't assume that people will have an enlightenment at the mere appearance of the word LD_LIBRARY_PATH. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Call for 7.5 feature completion
Joshua D. Drake wrote: > Also PHP does not compile the PostgreSQL support by default. But most binary packages do, and they are the ones I'm talking about. And surely you do not advocate that, in order to build PL/PHP, the packagers instead disable the client side support in PHP? ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Call for 7.5 feature completion
But most binary packages do, and they are the ones I'm talking about. And surely you do not advocate that, in order to build PL/PHP, the packagers instead disable the client side support in PHP? Of course not, but I still don't see your point. plPHP doesn't need PHP+PostgreSQL support. Nor does PHP+PostgreSQL conflict with using plPHP... PHP doesn't even need to be installed for plPHP to work... You just need the source tree for building. So I am confused... Sincerely, Joshua D. Drake ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Why new features only in magior releases ?
Neil Conway wrote: Gaetano Mendola wrote: I well understand the reason to wait a 7.5 in order to delivery BIG changes that are requiring a initdb, but I don't understand why little enhancement can not be delivered in a 7.4.3 ( may be with a short period with a 7.4.3beta ) like the "vacuum delayed". I don't think this is a good idea. It would risk destabilizing a known-to-be-stable release series. It is very important that we keep 7.4.x a platform that people feel comfortable deploying in a production environment. Then we miss a degree in the versioning. I'm with you about: 1) Avoid init db if the BIG version not change 2) Avoid to introduce instability in a "know-to-be-stable" release but wait "one year" for little improvement that for sure are not going to jeopardize the two points aboce is too much IMHO ( see the vacuumdb delayed ). It would also require additional development resources to back port the changes, and do the (fairly extensive) testing required to verify that they haven't caused any regressions (see the point about stability above). We have a finite amount of development resources, and I think the past consensus is that they are best spent developing for the next major release. Currently some changes are back ported to old branches ( BTW, why not to switch to use "subversion"? ) so I don't think this actualy a big issue, some times some improvments introduced in the BETA cicle are just postponed to next version, so some times there is no back porting but "front" porting. I think that delivering some improvements in the 7.4.3 will permit to delay a month the 7.5 without the pain to wait too long for some enhancements. Even without new features in 7.4, I don't really see the danger of a slow-paced 7.5 release: production environments aren't eager to upgrade their DBMS every six months, and the pain of an initdb applies no matter how frequently we make major releases. I agree, for this reason I'm for introduce in old version ) that avoid to perform an initdb) future enhancements. We are running our DB in an RedHat HA cluster and upgrade from 7.X.Y -> 7.X.Z for us is just an "eye blink", rpm -Uvh on the backup node, we relocate the service, rpm -Uvh on the main node; all this with a total outage of less then one minute. Regards Gaetano Mendola ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Relocatable installs
Bruce Momjian wrote: Peter Eisentraut wrote: Bruce Momjian wrote: > We already have --disable-rpath. Seems we would just need something > to use the *.a files. I think it is perfectly sufficient to say that if you want a relocatable install, don't use rpath. Static linking will lead to all other kinds of madness. OK, but if we don't use rpath, don't we have to do the ld.so.conf or environment varaible usage so we can find our shared library. I assume the big problem with rpath is that it might find the wrong version of our library, right? Is there another downside to it being set? Exactly. Suppose you have one of these silly RPM based Linux systems. One has to install PostgreSQL from RPM's in order to satisfy all the dependencies for whatever else you want. Now you want to install a relocatable version of PostgreSQL somewhere else, because you don't want to mess up the RPM installed one. For sure the ld.so.conf is setup to find the RPM installed version of libpq. That's why we use rpath, so that you can install PG somewhere else and the /usr/local/pg75/bin/psql will find the libpq in /usr/local/pg75/lib instead of /usr/lib. But that's currently a configure time option and removing rpath altogether will let everything find the old libpq. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Relocatable installs
Peter Eisentraut wrote: Bruce Momjian wrote: We already have --disable-rpath. Seems we would just need something to use the *.a files. I think it is perfectly sufficient to say that if you want a relocatable install, don't use rpath. Static linking will lead to all other kinds of madness. Boy, nobody was suggesting 100% static linking. What kind of madness are you getting into if you link libpq.a into psql? There is something between all or nothing, isn't there? Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Relocatable installs
Peter Eisentraut wrote: > Bruce Momjian wrote: > > We already have --disable-rpath. Seems we would just need something > > to use the *.a files. > > I think it is perfectly sufficient to say that if you want a relocatable > install, don't use rpath. Static linking will lead to all other kinds > of madness. OK, I added some more documentation about how to make relocatable installs. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 Index: doc/src/sgml/installation.sgml === RCS file: /cvsroot/pgsql-server/doc/src/sgml/installation.sgml,v retrieving revision 1.199 diff -c -c -r1.199 installation.sgml *** doc/src/sgml/installation.sgml 17 May 2004 16:06:25 - 1.199 --- doc/src/sgml/installation.sgml 18 May 2004 20:33:18 - *** *** 503,508 --- 503,518 installation. (The man and doc locations are not affected by this.) + + + For relocatable installs, you might want to use + configure's --disable-rpath + option. Also, you will need to tell the operating system how + to find the shared libraries used by applications like + psql either using a system-wide shared + library configuration file like ld.so.conf, + or an environment variable like LD_LIBRARY_PATH. + ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Relocatable installs
Peter Eisentraut wrote: > Bruce Momjian wrote: > > We already have --disable-rpath. Seems we would just need something > > to use the *.a files. > > I think it is perfectly sufficient to say that if you want a relocatable > install, don't use rpath. Static linking will lead to all other kinds > of madness. OK, but if we don't use rpath, don't we have to do the ld.so.conf or environment varaible usage so we can find our shared library. I assume the big problem with rpath is that it might find the wrong version of our library, right? Is there another downside to it being set? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Relocatable installs
Bruce Momjian wrote: > We already have --disable-rpath. Seems we would just need something > to use the *.a files. I think it is perfectly sufficient to say that if you want a relocatable install, don't use rpath. Static linking will lead to all other kinds of madness. Also, some platforms offer relative rpaths. (Maybe Solaris is the only one.) We could make use of that. ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Call for 7.5 feature completion
Joshua D. Drake wrote: > > This is very much different, because the PHP distribution contains > > the PostgreSQL driver, whereas the other languages do not. So you > > would have > > > > PHP build depends on PostgreSQL > > Ahh I see your point, EXCEPT :) plPHP does not require PostgreSQL > support to be built into PHP. That is irrelevant. A normal binary package of PHP does build the PostgreSQL support (which is surely in our interest), so the build dependency holds. > > Sincerely, > > Joshua D. Drake > > > PostgreSQL build depends on PHP > > > > Not good. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Call for 7.5 feature completion
That is irrelevant. A normal binary package of PHP does build the PostgreSQL support (which is surely in our interest), so the build dependency holds. Then I am afraid I don't understand the actual problem. plPHP does not create a circular dependency because it doesn't require PHP to have PostgreSQL support. Also PHP does not compile the PostgreSQL support by default. This is no different that Perl, which also has a PostgreSQL driver but plPerl does not require DBD::Pg to compile. Sincerely, Joshua D. Drake Sincerely, Joshua D. Drake PostgreSQL build depends on PHP Not good. -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL begin:vcard fn:Joshua D. Drake n:Drake;Joshua D. org:Command Prompt, Inc. adr:;;PO Box 215;Cascade Locks;Oregon;97014;USA email;internet:[EMAIL PROTECTED] title:Consultant tel;work:503-667-4564 tel;fax:503-210-0034 note:Command Prompt, Inc. is the largest and oldest US based commercial PostgreSQL support provider. We provide the only commercially viable integrated PostgreSQL replication solution, but also custom programming, and support. We authored the book Practical PostgreSQL, the procedural language plPHP, and adding trigger capability to plPerl. x-mozilla-html:FALSE url:http://www.commandprompt.com/ version:2.1 end:vcard ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] proposal: be smarter about i/o patterns in index scan
> The basic problem is that Pg seeks far too much when performing an index > scan. I have saved an strace of a backend which is selecting 170,000 > rows from a 240,000,000 row table via index scan. The strace shows > 134,000 seeks and reads, or almost one seek for every tuple in the > result set. This would be fine normally except the seeks are in a > *very* suboptimal pattern, swinging back and forth across the device. > The query requires 16 minutes, 30 seconds on our test hardware. Yes yes yes *please* fix this :-) This performance bottle neck in PG effects us all the time. > The proposal is to sort the block requests before they are issued. > Because Pg only issues single seek/read pairs synchronously, the kernel > has no chance to apply its elevator and hence every seek/read Pg issues > results in actual movement of the disk head. Pg's random pattern of > seeking also makes the kernel's readahead fairly useless. > > To prove the proposal I did a simulation, using the recorded seek > positions in the strace. We noted that Pg issued 403 seek/read pairs > for every 8192 bytes read from the index. So we performed four > simulations: a straight playback of Pg's seek pattern, a playback where > each list of 403 seeks is sorted by byte offset, a playback of all the > seeks sorted by offset, and a sequential scan of the 13GB data file. > > PostgreSQL 4.2.1: 16m30s > Sorted in chunks: 10m6s > Sorted altogether: 4m19s > Sequential scan: 6m7s > > As you can see, there's a lot to be gained here. If Pg was able to > issue its seeks in the optimal order, the query would return in 1/4th > the time. Even the chunk-sorted scheme is a big win. I think your worst case may not be as bad as it gets. Nothing scientific, but my experience tells me that it's common to get even worse performance than that. I've had queries that would take seemingly forever, but then after a fresh cluster and cache flush, the same query would take almost no time at all. I also think that with a multi-mirrored RAID setup and your proposed IO sorting, the mirroring would be more likely to overcome seek overhead. With the current implementation, it seems almost useless to throw more hardware at the problem. I think the improvement would be even 'huger' than your numbers show :-) > So the proposal is this: the offsets stored in the index ought to be > sorted. Either A) they can be stored sorted in the first place (sorted > in VACUUM ANALYZE, or always sorted), or B) the backend can sort each > list of tuples it reads from the index, or C) the backend can read the > entire index result and sort that (this would be the best). > > >From just paging through the code, it doesn't seem terribly hard. B > seems the easiest to implement but is also the least improvement. Even > seqscan is better than B. One improvement to B would be to read much > more than 8K from the index. Reading e.g. 256KB would improve things > dramatically. A might be easy but would either degrade over time or > cause slower inserts. C is the best and hardest to implement (I am > guessing, because the size of sorted index subset is unbounded). IMO if you're going to do it, do it right. That means A is pretty much out, again, IMO. It would seem that B (improved) would be the way to go because, as you say, C would produce unbounded subsets. I would propose to read very large sections of the index subset though, more in the order of several MB (configurable, of course). With that much space to play with, most queries would require only one pass at the index and therefore show performance equal to C. Larger queries would suffer a bit, but then we don't usually have such speedy expectations of large expected result sets, and again, with enough sort space to play with, the performance could approach that of C. I would think that you could also sort the index on index order (during vacuum) to improve index scan performance. This could be a completely seperate implementation task. With clean sequential index access *and* clean sequential heap access, it might just prove to be the single largest performance boost PG has seen, well, ever. My .02... Glen Parker ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Call for 7.5 feature completion
This is very much different, because the PHP distribution contains the PostgreSQL driver, whereas the other languages do not. So you would have PHP build depends on PostgreSQL Ahh I see your point, EXCEPT :) plPHP does not require PostgreSQL support to be built into PHP. Sincerely, Joshua D. Drake PostgreSQL build depends on PHP Not good. -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL begin:vcard fn:Joshua D. Drake n:Drake;Joshua D. org:Command Prompt, Inc. adr:;;PO Box 215;Cascade Locks;Oregon;97014;USA email;internet:[EMAIL PROTECTED] title:Consultant tel;work:503-667-4564 tel;fax:503-210-0034 note:Command Prompt, Inc. is the largest and oldest US based commercial PostgreSQL support provider. We provide the only commercially viable integrated PostgreSQL replication solution, but also custom programming, and support. We authored the book Practical PostgreSQL, the procedural language plPHP, and adding trigger capability to plPerl. x-mozilla-html:FALSE url:http://www.commandprompt.com/ version:2.1 end:vcard ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Relocatable installs
Jan Wieck wrote: If I remore the whole -rpath thing, and remove the two -L options and the -lpq and -lpgport, and add the libpq.a and libpgport.a explicitly to the linker call, the psql executable on my Linux box grows from 421761 to 677682 bytes in size. It is still shared linked against libc, libz, libreadline and a bunch of otheres, but all of them are in /lib or /usr/lib, so they are standard or system libraries. It does not depend on a libpq.so any more, and that is what we want. One of the reasons I originally suggested an explicit 'relocatable' config option was worry about the rpath thing. Maybe I should have raised red flags a bit more ;-) Static linking against libpq would have considerable advantages for the Windows port (see recent discussion regarding library search paths on W32 on the w32-hackers list). cheers andrew ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Call for 7.5 feature completion
Marko Karppinen wrote: > I guess the key thing is that pgFoundry shouldn't be a community > distinct from the core. The same community standards need to apply > on both sides of the fence. Yes, and the best way to achieve that would be to not have anything to pgfoundry and keep everything in the core. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Call for 7.5 feature completion
Joshua D. Drake wrote: > >One reason against including plPHP in the core would be that it > > would create a circular build dependency between the packages > > postgresql and php. I think we should rather avoid that. > > It is no different that the dependency between plPerl and Perl, > plPython and Python or worse > plTCL and TCL (which typically isn't installed anymore). This is very much different, because the PHP distribution contains the PostgreSQL driver, whereas the other languages do not. So you would have PHP build depends on PostgreSQL PostgreSQL build depends on PHP Not good. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Relocatable installs
Jan Wieck wrote: > > Static linking of our binaries? Hmmm. Makes sense. We would need a > > special flag for that. I can add it to the TODO. > > > > Seems my testing was flawed because I didn't clean out my hard-coded > > directory properly. I see now: > > > > $ bin/initdb > > bin/initdb: can't load library 'libpq.so.3' > > > > and I see in my initdb link line: > > > > -Wl,-rpath,/usr/local/pgsql/lib > > If I remore the whole -rpath thing, and remove the two -L options and > the -lpq and -lpgport, and add the libpq.a and libpgport.a explicitly to > the linker call, the psql executable on my Linux box grows from 421761 > to 677682 bytes in size. It is still shared linked against libc, libz, > libreadline and a bunch of otheres, but all of them are in /lib or > /usr/lib, so they are standard or system libraries. It does not depend > on a libpq.so any more, and that is what we want. We already have --disable-rpath. Seems we would just need something to use the *.a files. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Relocatable installs
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Greg Stark wrote:
> > Jan Wieck <[EMAIL PROTECTED]> writes:
> >
> > > You know how much trouble that causes? The existance of LD_LIBRARY_PATH in your
> > > environment disables setuid() for security reasons on some platforms. So one
> > > would have to wrap every PG related program into equally named shell scripts or
> > > aliases to just set it for the program call alone.
> >
> > Why would any pg tools need to be setuid?
>
> I assume he is saying that you would have problems having that set all
> the time. You would need to set it only before running pg binaries,
> which is a pain.
I've never heard of any system where that's the case. Normally the loader
simply ignores the LD_LIBRARY_PATH LD_PRELOAD etc. for setuid/setgid programs.
I feel weird here giving ammunition that LD_LIBRARY_PATH is happy while
simultaneously arguing it shouldn't be used though.
> > > Relocatable installation means static linking of our tools against our own
> > > libs. This does not mean static linking entirely, but at least static linking
> > > against libpq.a.
> >
> > The normal approach is to use rpath for relocatable installs.
> > That's what it's there for.
> > Static linking would work too but it's overkill.
>
> The point is that we want someone to be able to do an install, and then
> be able to move the pgsql directory. When we use rpath, the installed
> binary has a hardcoded path for the libraries.
You do? That doesn't generally work. To do that you have to break all the unix
conventions about config files in /etc, platform independent files in /share,
modified data in /var, etc. I know postgres currently violates these
conventions, but most unix programs don't so anyone who has such an
expectation is in for a lot of surprises.
And long term I expect postgres to head in the direction of complying with
these conventions so distributions can stop kludging around the violations
with symlinks and wrapper scripts. Writing in more assumptions about the
non-standard installation will only create more pain down the road.
Generally I've only heard "relocatable" to refer to RPM packages that could be
installed to a non-standard prefix. For that you need an install script that
knows what magic has to be done. Not a directory that can be moved around
willy-nilly *after* installation.
> > But please don't use rpath for installs to standard paths like
> > /usr/{local,}/lib. That way lies madness.
>
> We don't. By default it is /usr/local/pgsql/lib, which isn't standard.
Well that sucks, but that's for another day :)
As long as it is in a non-standard location then rpath really ought to be set.
Requiring every user of a program to set environment variables before it works
properly is lame. It engenders the kde/qt/oracle headaches of having to adjust
LD_LIBRARY_PATH for every user every time you install or update a package.
Of course rpath is evil, which is precisely why packages ought not be
installed in such non-standard locations...
--
greg
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Relocatable installs
Bruce Momjian wrote: Jan Wieck wrote: Bruce Momjian wrote: > Jan Wieck wrote: >> > I think if we go for the plan outlined, we will not need a special >> > configure flag. (People might decide to move the install dir long after >> > they install it.) By default, everything sits under pgsql as pgsql/bin, >> > pgsql/lib, etc. I can't see how making it relative is going to bite us >> > unless folks move the binaries out of pgsql/bin. Is that common for >> > installs that don't specify a special bindir? >> > >> >> Does that include a mechanism for -rpath? >> >> Currently, if you have multiple installations of PostgreSQL on a server >> and call ones psql or whatever explicitly, it is not loading another >> ones libpq, but for sure the one belonging to its version. How does the >> plan you're talking about cover this? > > Someone asked about rpath, and I didn't deal with it. How many > platforms use rpath? I am not sure. > > I assume folks are going to have to modify their ld.so.conf to point to > the proper library, or for non-root, set an environment variable like > LD_LIBRARY_PATH. You know how much trouble that causes? The existence of LD_LIBRARY_PATH Nope. in your environment disables setuid() for security reasons on some platforms. So one would have to wrap every PG related program into equally named shell scripts or aliases to just set it for the program call alone. OK. Relocatable installation means static linking of our tools against our own libs. This does not mean static linking entirely, but at least static linking against libpq.a. Static linking of our binaries? Hmmm. Makes sense. We would need a special flag for that. I can add it to the TODO. Seems my testing was flawed because I didn't clean out my hard-coded directory properly. I see now: $ bin/initdb bin/initdb: can't load library 'libpq.so.3' and I see in my initdb link line: -Wl,-rpath,/usr/local/pgsql/lib If I remore the whole -rpath thing, and remove the two -L options and the -lpq and -lpgport, and add the libpq.a and libpgport.a explicitly to the linker call, the psql executable on my Linux box grows from 421761 to 677682 bytes in size. It is still shared linked against libc, libz, libreadline and a bunch of otheres, but all of them are in /lib or /usr/lib, so they are standard or system libraries. It does not depend on a libpq.so any more, and that is what we want. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Call for 7.5 feature completion
Joshua D. Drake wrote: > >Except you miss one key point here ... if Bruce/Tom/Jan have that sort of > >time, why aren't they doing it now? > > > > > Well I think you might of missed his point. His point was if he could > pick their priorities. I would kind > of agree with Robert except that there are other dynamics involved... > Jan works for Afilias thus does > what Afilias directs him to do and what that is right now is Slony-I. > > Tom works for RedHat but from what I can tell is basically a rogue agent I like the "rogue agent". I want to be one too. :-) > ;). However if Tom stops > works what he is doing to help with PITR etc... I think a lot of the > innner world of PostgreSQL would > simply stop (if I am wrong please correct me). Bruce --- well what can > you say about Bruce ;). > > Seriously though, we all have the roles that we play. I don't think > redirecting specific resources to other > resources will help beyond slowing up the original resources. Tom is actually working on doing the fsync change for Win32 and to remove the unix dependency on sync, so in a way he is on the Win32 train right now. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Relocatable installs
Greg Stark wrote: Jan Wieck <[EMAIL PROTECTED]> writes: You know how much trouble that causes? The existance of LD_LIBRARY_PATH in your environment disables setuid() for security reasons on some platforms. So one would have to wrap every PG related program into equally named shell scripts or aliases to just set it for the program call alone. Why would any pg tools need to be setuid? That's got nothing to do with what I said. Setting LD_LIBRARY_PATH will possibly affect everything else that needs setuid. But it's just wrong to have a binary that doesn't run unless you have environment variables set up. Relocatable installation means static linking of our tools against our own libs. This does not mean static linking entirely, but at least static linking against libpq.a. The normal approach is to use rpath for relocatable installs. That's what it's there for. Static linking would work too but it's overkill. I don't mean complete static linking. But what's wrong with linking psql and other PostgreSQL utilities against libpq.a instead of libpq.so? Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Table Spaces
> [EMAIL PROTECTED] wrote: > >> This makes me worried. That's the way we *used* to do things, but the >> sleazy IP lawyers are looking for anything with which they can create >> the >> impression of impropriety. The open source and free projects are ground >> zero for this crap. >> >> We *really* need to be careful. > > I assumed this tool was GPL and we just needed to avoid the GPL issue. I'm probably just being alarmist, but think about some IP lawyer buying up the entity that owns the GPL code, and suing end user's of PostgreSQL. This is similar to what is happening in Linux land with SCO. The best defense is to say, nope, we didn't copy your stuff, we implemented it ourselves based on the documentation. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Call for 7.5 feature completion
Marc G. Fournier wrote: On Tue, 18 May 2004, Robert Treat wrote: Just like Bruce has often asked the community how they feel about him balancing his time between things like speaking engagements and patch applications, core developers have a limited amount of time they can spend on any given development effort. If I had to pick (If I got to pick?), I would rather see Bruce/Tom/Jan working on helping these guys finish PITR/WIN32/Tablespaces/etc... than working on closing the 7.5 branch. Except you miss one key point here ... if Bruce/Tom/Jan have that sort of time, why aren't they doing it now? Well I think you might of missed his point. His point was if he could pick their priorities. I would kind of agree with Robert except that there are other dynamics involved... Jan works for Afilias thus does what Afilias directs him to do and what that is right now is Slony-I. Tom works for RedHat but from what I can tell is basically a rogue agent ;). However if Tom stops works what he is doing to help with PITR etc... I think a lot of the innner world of PostgreSQL would simply stop (if I am wrong please correct me). Bruce --- well what can you say about Bruce ;). Seriously though, we all have the roles that we play. I don't think redirecting specific resources to other resources will help beyond slowing up the original resources. Sincerely, Joshua D. Drake Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL
Re: [HACKERS] bitwise and/or aggregate functions?
Alvaro Herrera Munoz wrote: Those are PDFs AFAIR, not easily greppable Not greppable, but any half-decent PDF viewer should have a "search" feature that should allow much the same thing. Checking the index is another way to go, although it is somewhat time-consuming. I don't have access to an ASCII version (of SQL2003; I believe I've got an ASCII copy of SQL92 around here somewhere). -Neil ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Table Spaces
[EMAIL PROTECTED] wrote: > >> Let's just make sure we keep records of the generic sources of where we > >> find things. I get *really* scared when I see sentences like "I assume > >> we > >> can just look at the source and write our own version bypassing any > >> license." That is categorically a false asumption and will create an > >> arguably derived product. The last thing we want is Oracle or Microsoft > >> trying to pull an SCO on Postgresql. > > > > Usually we look at the source, find out how they do it, then find the > > docs for the underlying functions, and use that. > > This makes me worried. That's the way we *used* to do things, but the > sleazy IP lawyers are looking for anything with which they can create the > impression of impropriety. The open source and free projects are ground > zero for this crap. > > We *really* need to be careful. I assumed this tool was GPL and we just needed to avoid the GPL issue. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Call for 7.5 feature completion
On Tue, 2004-05-18 at 09:30, Andrew Sullivan wrote: > On Sun, May 16, 2004 at 02:46:38PM -0400, Jan Wieck wrote: > > > fact that checkpoints, vacuum runs and pg_dumps bog down their machines > > to the state where simple queries take several seconds care that much > > for any Win32 port? Do you think it is a good sign for those who have > > Yes. I am one such person, but from the marketing side of things, I > understand perfectly well what failing to deliver on Win32 again will > cost. It's not important to _me_, but that doesn't mean it's > unimportant to the project. > My primary fear about delivering Win32 with all of these other great features is that, IMO, there is a higher level of risk associated with these advanced features. At the same time, this will be the first trial for many Win32 users. Should there be some problems, in general, or worse, specific to Win32 users as it relates to these new features, it could cost some serious Win32/PostgreSQL community points. A troubled release which is experienced by Win32 users is going to be a battle cry for MySQL. I've been quietly hoping that these great new features would become available a release before Win32 was completed. That way, a shake down would occur before the Win32 audience got a hold of it. Which, in turn, should make for a great Win32 experience. I guess my point is, if these other features don't make it into 7.5 and Win32 does, that might still be a "good thing" for the potential Win32 market. Granted, if I was a developer on one of these big features and it didn't make it, I too would be fairly disappointed. Yet, once we get a release out with Win32, it should help give everyone a feel for the ability to actually support this new audience and platform. If there is a large influx of users compounded by problems, I suspect it's again, going to reflect poorly on the PostgreSQL community. ...just some ramblings -- Greg Copeland, Owner [EMAIL PROTECTED] Copeland Computer Consulting 940.206.8004 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Table Spaces
> [EMAIL PROTECTED] wrote: >> >> >> >We've looked at it before. Apart from anything else I don't think >> >> >> >its license is compatible with PostgreSQL's. >> >> >> >> >> >> Well, people can still use it. We just can't distribute >> >> it... We can >> >> >> always link to it. >> >> >> But unless there is a GUI tool (actually, unless it shows up in >> the >> >> >> *default* GUI tool), expect there to be questions. An >> >> > >> >> > I assume we can just look at the source and write our own version >> >> > bypassing any license. >> >> >> >> I wouldn't be so sure about that. If this insane SCO crap has >> >> taught me anything, the PostgreSQL should have a defined and >> >> legally vetted process for duplicating functionality. ala' >> >> phoenix BIOS. >> > >> > There is more than enough information om MSDN and other sites to make >> > this kind of tool without looking at the source. It's generic enough. >> >> Let's just make sure we keep records of the generic sources of where we >> find things. I get *really* scared when I see sentences like "I assume >> we >> can just look at the source and write our own version bypassing any >> license." That is categorically a false asumption and will create an >> arguably derived product. The last thing we want is Oracle or Microsoft >> trying to pull an SCO on Postgresql. > > Usually we look at the source, find out how they do it, then find the > docs for the underlying functions, and use that. This makes me worried. That's the way we *used* to do things, but the sleazy IP lawyers are looking for anything with which they can create the impression of impropriety. The open source and free projects are ground zero for this crap. We *really* need to be careful. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] bitwise and/or aggregate functions?
On Tue, May 18, 2004 at 12:39:08PM -0400, Neil Conway wrote: > A copy that claims to "represent an almost indistinuishable delta on the > actual SQL 2003 database standard" is available online here: > > http://www.wiscorp.com/sql/sql_2003_standard.zip Those are PDFs AFAIR, not easily greppable ... do you have a text version, or do you always look up things by looking at the TOC? I'm not thrilled with the idea of reading all 1500 pages of it ... -- Alvaro Herrera (<[EMAIL PROTECTED]>) "El día que dejes de cambiar dejarás de vivir" ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Table Spaces
[EMAIL PROTECTED] wrote: > >> >> >We've looked at it before. Apart from anything else I don't think > >> >> >its license is compatible with PostgreSQL's. > >> >> > >> >> Well, people can still use it. We just can't distribute > >> it... We can > >> >> always link to it. > >> >> But unless there is a GUI tool (actually, unless it shows up in the > >> >> *default* GUI tool), expect there to be questions. An > >> > > >> > I assume we can just look at the source and write our own version > >> > bypassing any license. > >> > >> I wouldn't be so sure about that. If this insane SCO crap has > >> taught me anything, the PostgreSQL should have a defined and > >> legally vetted process for duplicating functionality. ala' > >> phoenix BIOS. > > > > There is more than enough information om MSDN and other sites to make > > this kind of tool without looking at the source. It's generic enough. > > Let's just make sure we keep records of the generic sources of where we > find things. I get *really* scared when I see sentences like "I assume we > can just look at the source and write our own version bypassing any > license." That is categorically a false asumption and will create an > arguably derived product. The last thing we want is Oracle or Microsoft > trying to pull an SCO on Postgresql. Usually we look at the source, find out how they do it, then find the docs for the underlying functions, and use that. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Why new features only in magior releases ?
Gaetano Mendola wrote: I well understand the reason to wait a 7.5 in order to delivery BIG changes that are requiring a initdb, but I don't understand why little enhancement can not be delivered in a 7.4.3 ( may be with a short period with a 7.4.3beta ) like the "vacuum delayed". I don't think this is a good idea. It would risk destabilizing a known-to-be-stable release series. It is very important that we keep 7.4.x a platform that people feel comfortable deploying in a production environment. It would also require additional development resources to back port the changes, and do the (fairly extensive) testing required to verify that they haven't caused any regressions (see the point about stability above). We have a finite amount of development resources, and I think the past consensus is that they are best spent developing for the next major release. I think that delivering some improvements in the 7.4.3 will permit to delay a month the 7.5 without the pain to wait too long for some enhancements. Even without new features in 7.4, I don't really see the danger of a slow-paced 7.5 release: production environments aren't eager to upgrade their DBMS every six months, and the pain of an initdb applies no matter how frequently we make major releases. -Neil ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] bitwise and/or aggregate functions?
[ Sorry for the latency of my response, Chris -- this got buried in my inbox... ] Fabien COELHO wrote: I don't know where these standards are available online... It seems they are not available:-( A copy that claims to "represent an almost indistinuishable delta on the actual SQL 2003 database standard" is available online here: http://www.wiscorp.com/sql/sql_2003_standard.zip Neil - can you check your SQL2003 copy to see if it mentions standard aggregates on bit types? I couldn't see any mention of any aggregates specific to the bit types, although my ability to accurately divine information from the standard has been less than perfect in the past. There are the EVERY() and ANY() aggregates that Fabien mentioned, though. -Neil ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Table Spaces
>> >> >We've looked at it before. Apart from anything else I don't think >> >> >its license is compatible with PostgreSQL's. >> >> >> >> Well, people can still use it. We just can't distribute >> it... We can >> >> always link to it. >> >> But unless there is a GUI tool (actually, unless it shows up in the >> >> *default* GUI tool), expect there to be questions. An >> > >> > I assume we can just look at the source and write our own version >> > bypassing any license. >> >> I wouldn't be so sure about that. If this insane SCO crap has >> taught me anything, the PostgreSQL should have a defined and >> legally vetted process for duplicating functionality. ala' >> phoenix BIOS. > > There is more than enough information om MSDN and other sites to make > this kind of tool without looking at the source. It's generic enough. Let's just make sure we keep records of the generic sources of where we find things. I get *really* scared when I see sentences like "I assume we can just look at the source and write our own version bypassing any license." That is categorically a false asumption and will create an arguably derived product. The last thing we want is Oracle or Microsoft trying to pull an SCO on Postgresql. ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Call for 7.5 feature completion
Marc G. Fournier wrote: > On Tue, 18 May 2004, Robert Treat wrote: > > > Just like Bruce has often asked the community how they feel about him > > balancing his time between things like speaking engagements and patch > > applications, core developers have a limited amount of time they can > > spend on any given development effort. If I had to pick (If I got to > > pick?), I would rather see Bruce/Tom/Jan working on helping these guys > > finish PITR/WIN32/Tablespaces/etc... than working on closing the 7.5 > > branch. > > Except you miss one key point here ... if Bruce/Tom/Jan have that sort of > time, why aren't they doing it now? I can answer that one. We only have limited time to help a limited number of folks. I have been Win32-focussed, so haven't had time to help anyone else, and even applying patches has been delayed and folks are complaining. I have talked to Jan about helping me get PITR done. It is very close and Jan said he would work on a patch to help. I think the poster's point was that once we enter feature freeze, we have even less time to help folks, hence no progress in PITR until long after 7.4. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Relocatable installs
Greg Stark wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
>
> > You know how much trouble that causes? The existance of LD_LIBRARY_PATH in your
> > environment disables setuid() for security reasons on some platforms. So one
> > would have to wrap every PG related program into equally named shell scripts or
> > aliases to just set it for the program call alone.
>
> Why would any pg tools need to be setuid?
I assume he is saying that you would have problems having that set all
the time. You would need to set it only before running pg binaries,
which is a pain.
> > Relocatable installation means static linking of our tools against our own
> > libs. This does not mean static linking entirely, but at least static linking
> > against libpq.a.
>
> The normal approach is to use rpath for relocatable installs.
> That's what it's there for.
> Static linking would work too but it's overkill.
The point is that we want someone to be able to do an install, and then
be able to move the pgsql directory. When we use rpath, the installed
binary has a hardcoded path for the libraries.
> But please don't use rpath for installs to standard paths like
> /usr/{local,}/lib. That way lies madness.
We don't. By default it is /usr/local/pgsql/lib, which isn't standard.
I see static linking as perhaps the only clean solution for relocatable
installs that require no user manipulation.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Relocatable installs
Jan Wieck wrote: > Bruce Momjian wrote: > > Jan Wieck wrote: > >> > I think if we go for the plan outlined, we will not need a special > >> > configure flag. (People might decide to move the install dir long after > >> > they install it.) By default, everything sits under pgsql as pgsql/bin, > >> > pgsql/lib, etc. I can't see how making it relative is going to bite us > >> > unless folks move the binaries out of pgsql/bin. Is that common for > >> > installs that don't specify a special bindir? > >> > > >> > >> Does that include a mechanism for -rpath? > >> > >> Currently, if you have multiple installations of PostgreSQL on a server > >> and call ones psql or whatever explicitly, it is not loading another > >> ones libpq, but for sure the one belonging to its version. How does the > >> plan you're talking about cover this? > > > > Someone asked about rpath, and I didn't deal with it. How many > > platforms use rpath? I am not sure. > > > > I assume folks are going to have to modify their ld.so.conf to point to > > the proper library, or for non-root, set an environment variable like > > LD_LIBRARY_PATH. > > You know how much trouble that causes? The existence of LD_LIBRARY_PATH Nope. > in your environment disables setuid() for security reasons on some > platforms. So one would have to wrap every PG related program into > equally named shell scripts or aliases to just set it for the program > call alone. OK. > Relocatable installation means static linking of our tools against our > own libs. This does not mean static linking entirely, but at least > static linking against libpq.a. Static linking of our binaries? Hmmm. Makes sense. We would need a special flag for that. I can add it to the TODO. Seems my testing was flawed because I didn't clean out my hard-coded directory properly. I see now: $ bin/initdb bin/initdb: can't load library 'libpq.so.3' and I see in my initdb link line: -Wl,-rpath,/usr/local/pgsql/lib So, right now, you can do relocatable installs, but you have to make changes in ld.so.conf or your environment to allow it to find the shared libraries. In the future, we can add a configure flag so everything is linked statically. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] Why new features only in magior releases ?
Hi all, may be this was already discussed, I'm quite new to postgres ( only 3 years ), I try however. I seen the debate around the time freeze for 7.5, who say to wait in order to have more "chance" to have PITR, Win32, 2PC... and who say that wait a month more will not change nothing. I well understand the reason to wait a 7.5 in order to delivery BIG changes that are requiring a initdb, but I don't understand why little enhancement can not be delivered in a 7.4.3 ( may be with a short period with a 7.4.3beta ) like the "vacuum delayed". I think that delivering some improvements in the 7.4.3 will permit to delay a month the 7.5 without the pain to wait too long for some enhancements. Regards Gaetano Mendola ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Call for 7.5 feature completion
On Sun, May 16, 2004 at 02:46:38PM -0400, Jan Wieck wrote: > fact that checkpoints, vacuum runs and pg_dumps bog down their machines > to the state where simple queries take several seconds care that much > for any Win32 port? Do you think it is a good sign for those who have Yes. I am one such person, but from the marketing side of things, I understand perfectly well what failing to deliver on Win32 again will cost. It's not important to _me_, but that doesn't mean it's unimportant to the project. A -- Andrew Sullivan | [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Table Spaces
> >> >We've looked at it before. Apart from anything else I don't think > >> >its license is compatible with PostgreSQL's. > >> > >> Well, people can still use it. We just can't distribute > it... We can > >> always link to it. > >> But unless there is a GUI tool (actually, unless it shows up in the > >> *default* GUI tool), expect there to be questions. An > > > > I assume we can just look at the source and write our own version > > bypassing any license. > > I wouldn't be so sure about that. If this insane SCO crap has > taught me anything, the PostgreSQL should have a defined and > legally vetted process for duplicating functionality. ala' > phoenix BIOS. There is more than enough information om MSDN and other sites to make this kind of tool without looking at the source. It's generic enough. //Magnus ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Relocatable installs
Jan Wieck <[EMAIL PROTECTED]> writes:
> You know how much trouble that causes? The existance of LD_LIBRARY_PATH in your
> environment disables setuid() for security reasons on some platforms. So one
> would have to wrap every PG related program into equally named shell scripts or
> aliases to just set it for the program call alone.
Why would any pg tools need to be setuid?
But it's just wrong to have a binary that doesn't run unless you have
environment variables set up.
> Relocatable installation means static linking of our tools against our own
> libs. This does not mean static linking entirely, but at least static linking
> against libpq.a.
The normal approach is to use rpath for relocatable installs.
That's what it's there for.
Static linking would work too but it's overkill.
But please don't use rpath for installs to standard paths like
/usr/{local,}/lib. That way lies madness.
--
greg
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] Table Spaces
> Magnus Hagander wrote: >> >>If you run NTFS, it's still possible to use arbitrary links. >> >In the Windows >> >>world, they are called junctions. Microsoft does not provide >> >a junction tool >> >>for some reason (perhaps because it's limited to NTFS). A >> >good tool, free >> >>and with source, can be found here >> >>http://www.sysinternals.com/ntw2k/source/misc.shtml#junction >> >I use this tool >> >>myself. Works like a charm. >> >> >> >> >> >> >> > >> >We've looked at it before. Apart from anything else I don't think its >> >license is compatible with PostgreSQL's. >> >> Well, people can still use it. We just can't distribute it... We can >> always link to it. >> But unless there is a GUI tool (actually, unless it shows up in the >> *default* GUI tool), expect there to be questions. An > > I assume we can just look at the source and write our own version > bypassing any license. I wouldn't be so sure about that. If this insane SCO crap has taught me anything, the PostgreSQL should have a defined and legally vetted process for duplicating functionality. ala' phoenix BIOS. What would be good is a "contaminated" developer specifying functionality, and detailing the various APIs needed (documenting the undocumented ones as nessisary) while someone else writes the code. It is the *only* legal unemcumbered methodology that will work. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Call for 7.5 feature completion
On Tue, 18 May 2004, Robert Treat wrote: > Just like Bruce has often asked the community how they feel about him > balancing his time between things like speaking engagements and patch > applications, core developers have a limited amount of time they can > spend on any given development effort. If I had to pick (If I got to > pick?), I would rather see Bruce/Tom/Jan working on helping these guys > finish PITR/WIN32/Tablespaces/etc... than working on closing the 7.5 > branch. Except you miss one key point here ... if Bruce/Tom/Jan have that sort of time, why aren't they doing it now? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Call for 7.5 feature completion
On Mon, 2004-05-17 at 19:39, Marc G. Fournier wrote:
> On Mon, 17 May 2004, Mike Mascari wrote:
> > Greg Stark wrote:
> > > Simon Riggs <[EMAIL PROTECTED]> writes:
> > >
> > >>I can't complete by 1 June. Think worse of me if you choose.
> > >
> > ...
> > > So in my perfect world I picture 7.5 freezing June 1 and releasing in July or
> > > so, giving a nice reliable simple upgrade for people who just want a safe 7.x
> > > series to upgrade to even after 8.0 comes out. PITR, nested transactions going
> > > into the CVS tree sometime in June or July and being frozen as 8.0 towards the
> > > end of the year.
> >
> > A quick google of "7.4 Win32 release" will reveal that the above was
> > precisely what was said about 7.4: it would be released to not hold
> > up important features like the IN optimization and a quick 7.5 would
> > have Win32 and PITR. It's almost as if a cron job reposts this
> > thread every 6 - 12 months. For those of us that are desirous of
> > PITR, it's a 6 month reposting that is becoming painful to read...
>
> k, let's think this through ... 7.4 was released, what, 6 months ago? And
> 6 months later, PITR still isn't ready? Is there some logic here that if
> 7.4 wasn't released, PITR would have been done any sooner?
>
Potentially yes. One thing all of the developers have said they want is
more feedback from some of the more expert developers, but if we go into
feature freeze then the focus of folks like Tom and Bruce will be on
completing release, not on helping out with these new features. We had
the original patch for PITR before 7.4 went into beta IIRC, but it then
had to sit through a lengthy beta process before Tom could do some final
code review and get things committed.
Just like Bruce has often asked the community how they feel about him
balancing his time between things like speaking engagements and patch
applications, core developers have a limited amount of time they can
spend on any given development effort. If I had to pick (If I got to
pick?), I would rather see Bruce/Tom/Jan working on helping these guys
finish PITR/WIN32/Tablespaces/etc... than working on closing the 7.5
branch.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [HACKERS] Call for 7.5 feature completion
Peter Eisentraut wrote: Joshua D. Drake wrote: Uhhh?? Are you ripping out all core pls then? plPerlNG is supposed to replace plPerl, I was talking with Bruce and he seemed to think that (as long as the code was good enough) that we could incorporate plPHP??? One reason against including plPHP in the core would be that it would create a circular build dependency between the packages postgresql and php. I think we should rather avoid that. It is no different that the dependency between plPerl and Perl, plPython and Python or worse plTCL and TCL (which typically isn't installed anymore). Sincerely, Joshua D. Drake -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL
Re: [HACKERS] Call for 7.5 feature completion
a release, etc ... I'd almost say that time would be better spent on coming up with an effective upgrade method so that upgrading to new releases is easier ... Please note that I'm not against the backporting, but do understand the arguments against it in terms of time and manpower ... I believe they are valid arguments too and if we were to do it we would definately need to be selective about "which" features get back ported but forward movement can be in the present tree as well. Joshua D. Drake Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] question about information_schema
On Tue, 18 May 2004, Dave Cramer wrote: > If I do create type testint8 as (i int8) and then select typbasetype > from pg_type where typname='testint8' the value is 0? You've created a complex type here, not a domain. See typtype and typrelid for this case. create domain testint8 as int8; will do what you were expecting. Kris Jurka ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] XactIsoLevel handling
In tcop/utility.c, the isolation level is set with a call like:
SetPGVariable("transaction_isolation", makeList(item->arg), false)
when a BEGIN SERIALIZABLE etc. call is made.
Why is the isLocal-parameter false? Couldn't it be true as well? It works
as it is, since the XactIsoLevel variable is reset to default value in
StartTransaction anyway, but it looks silly to me to define the variable
as a session variable when in fact it acts like a local one.
I bumped into this because my current 2PC doesn't allow you to set session
variables. I modified the above line, and BEGIN SERIALIZABLE seems to
work fine now with 2PC.
- Heikki
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] Relocatable installs
Bruce Momjian wrote: Jan Wieck wrote: > I think if we go for the plan outlined, we will not need a special > configure flag. (People might decide to move the install dir long after > they install it.) By default, everything sits under pgsql as pgsql/bin, > pgsql/lib, etc. I can't see how making it relative is going to bite us > unless folks move the binaries out of pgsql/bin. Is that common for > installs that don't specify a special bindir? > Does that include a mechanism for -rpath? Currently, if you have multiple installations of PostgreSQL on a server and call ones psql or whatever explicitly, it is not loading another ones libpq, but for sure the one belonging to its version. How does the plan you're talking about cover this? Someone asked about rpath, and I didn't deal with it. How many platforms use rpath? I am not sure. I assume folks are going to have to modify their ld.so.conf to point to the proper library, or for non-root, set an environment variable like LD_LIBRARY_PATH. You know how much trouble that causes? The existance of LD_LIBRARY_PATH in your environment disables setuid() for security reasons on some platforms. So one would have to wrap every PG related program into equally named shell scripts or aliases to just set it for the program call alone. Relocatable installation means static linking of our tools against our own libs. This does not mean static linking entirely, but at least static linking against libpq.a. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] add server include files to default installation?
Dear Jan, > Depending on the OS you also need funny things like mkldexport shell > scripts and the like. Possibly, yes... I don't know. I really need a list, then it is pretty easy to update all makefiles. > I thought we had a consensus of providing a template build environment > for external modules. Good! Where is it? I mean the template, not the consensus. > This half-baked attempt is not doing it. The makefiles make assumptions > about their location that aren't true any more when they're installed > somewhere else. I noticed and took care of this point. In fact, it really depends on top_builddir, so by setting this macro appropriately it should work. Something like: top_builddir := $(shell pg_config --insbuilddir) include $(top_builddir)/src/Makefile.global This mean that relevant files must be installed in subdirectories that are named as the postgresql source tree... I agree that it is not beautiful, but it seems to me that it is the simplest way to have contrib-like makefiles outside of the main tree, and to be able to reuse the whole infrastructure. Obviously, any better idea is welcome, esp. if I do not have to do it myself;-) The current status is that *nothing* is provided, so I'm trying to have something better than nothing with a reasonnable effort. -- Fabien Coelho - [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] add server include files to default installation?
Marc G. Fournier wrote: On Sat, 15 May 2004, Bruce Momjian wrote: Fabien COELHO wrote: > > Dear hackers, > > I wish to submit a small patch so that server includes and > all necessary configuration files could be installed *by default*. > > The current status is that server includes files are only installed > if explicitly required (make install-all-headers). > > The idea is that external extension modules (new types or whatever) > could then *rely* on the fact that these files are available, which > would make developping and installing these extensions quite easier. > > As an illustration, the apache software installs by default all > necessary includes and even a special tailored command (apxs) so as > to help extension modules to be compiled, installed and even configured > easilly. > > Is there any opposition to this move? Silence will mean consent;-) Agreed. I would also like to see Makefile.global installed. pg_config.h has C-level configs, and Makefile.global has the Makefile-level configs. Don't agree with Makefile.global, cause then you have to also install the physical template files for the various operating system too, no? What else does Makefile.global rely on? Depending on the OS you also need funny things like mkldexport shell scripts and the like. I thought we had a consensus of providing a template build environment for external modules. This half-baked attempt is not doing it. The makefiles make assumptions about their location that aren't true any more when they're installed somewhere else. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] question about information_schema
I'm trying to implement getUDT for the jdbc driver. It requires the basetype of a type. If I do create type testint8 as (i int8) and then select typbasetype from pg_type where typname='testint8' the value is 0? While I'm asking how can I find all of the user defined types, assuming that the user is the owner of the cluster. I see that pg_dump can do this ? -- Dave Cramer 519 939 0336 ICQ # 14675561 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Call for 7.5 feature completion
> > That is the plan ... unless someone knows a reason why they > can't be > > built independently of the core? > > How about this one: Everything we have moved from the core > to gborg so far has been a miserable failure. The code is no > longer maintained, or maintained by three different competing > groups, the documentation has disappeared, the portability is > no longer taken care of, and only the bravest souls even dare > look at the stuff. I think before you move anything more, > you need to have a strong, convincing community on the > receiving side rather than just kicking things out and hoping > someone will pick it up. Just because it can be built > separately doesn't mean everything needs to be. Another thing is how the end user gets to the files. As an end user, you'd generally not care which CVS server the code is on. What you *do* care about is that it's included in the main RPM/DEB or whatever *and* the main source tarball (if I download "complete server", I certainly want a complete server. Including for example PLs, which is one of postgresqls strengths..). Same goes for the docs, of course. If it's in main CVS you get the benefit of having it included in the normal "release management". Sure, it adds a burden on the release management work, but that job has to be done somewhere. And id you just pull in "whatever version happens to be latest" and put this in the release version, you are probably in for some nasty surprises. //Magnus ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Call for 7.5 feature completion
On Mon, 17 May 2004, Alvaro Herrera Munoz wrote: > On Mon, May 17, 2004 at 04:55:50PM +0200, Zeugswetter Andreas SB SD wrote: > > Can we try to do the 2PC patch now instead of waiting for subtransactions ? > > The last post from Heikki I read said that he discovered some serious > problems with his implementation and he wanted do rethink about them. I > don't think he will be able to make it, mainly because if my patch gets > accepted it will be too close to feature freeze (if it is June 1st). That's still the status with my 2PC patch. It works, as long as you don't try to touch system catalogs, use notifications, set session GUC variables or do any other fancy stuff. In those cases you get a "not implemented" error when you try to prepare the transaction, and the it aborts. I think I figured out the MVCC snapshot issues, but I haven't really tested it so there could be some nasty race conditions I missed. I won't make it to June 1., I'll be on vacation on May 20-27, and I'm quite busy at work at the moment. I'd like to get the patch committed as soon as the 7.6 release cycle begins, with whatever limitations it has at that time. - Heikki ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Call for 7.5 feature completion
Marko Karppinen wrote: I guess the key thing is that pgFoundry shouldn't be a community distinct from the core. The same community standards need to apply on both sides of the fence. [snip] Thanks Marko, you just wrote exactly what I was concerned about with "features" rather than "applications" being in pgfoundry. The only thing I'd add is that we need to separate development from delivery. The important thing as an end-user is not where the CVS is kept or how things are kept in-sync but: 1. Can I get hold of it easily? 2. Is it mentioned in the manual? 3. Do I know what versions of PG/other it needs? pl/PHP etc might not need to be in the core CVS or tar.gz, but probably do need to be in a pl/ or plugins/ directory on the main site. If it takes a week or two (after release) for the various plugins to appear, that's fine - no-one upgrades a production system on day 1 anyway. Perhaps this is the best way to look at it - when the .rpm's/.deb's are put together what does the community want in them? -- Richard Huxton Archonet Ltd ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [PATCHES] Current-stream read for psql's \copy
Bruce Momjian wrote:
Also, I came upon this gem:
$ echo '\\copy test to stdout' | psql -o /tmp/z test
444
444
444
444
444
Seems 'copy to stdout' also has this split idea of sending \copy output
to a different place from other output.
I guess my big question now is why someone would use \copy stdin/stdout
for reading input from the command stream when they can use COPY?
I think the idea was that you could have a program that does something
like (Perl):
my $fh = open('| psql -f commands.sql');
print $fh "1\ta\n";
Where commands.sql contains the \copy.
I'm not saying that was the original intention, but someone pointed out
you could do things that way, and I can see it might (rarely) be useful.
--
Richard Huxton
Archonet Ltd
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
Re: [HACKERS] Call for 7.5 feature completion
Peter Eisentraut wrote: How about this one: Everything we have moved from the core to gborg so far has been a miserable failure. The code is no longer maintained, or maintained by three different competing groups, the documentation has disappeared, the portability is no longer taken care of, and only the bravest souls even dare look at the stuff. I think before you move anything more, you need to have a strong, convincing community on the receiving side rather than just kicking things out and hoping someone will pick it up. Just because it can be built separately doesn't mean everything needs to be. I guess the key thing is that pgFoundry shouldn't be a community distinct from the core. The same community standards need to apply on both sides of the fence. What has happened here echoes the experiences of the PHP project very closely. PHP, too, thought that the core was getting too big for efficient release coordination, and started moving extensions to PECL, an extension library bolted on the side of PEAR. Trouble is, nobody wants to be forced into the ghetto. The only way to make pgFoundry work is to minimize the downside of living there. Consider these: - Don't move just "inessential" projects. Move absolutely essential projects to push end-user and developer adoption. - Have a tier of "official" projects that are actively endorsed by and within the core distribution. Don't be afraid to pick a favorite solution within a class (for example in replication). - Discourage other developers from ignoring pgFoundry projects. For the official tier, this could mean sending commit messages to pgsql-committers, patches to pgsql-patches, and having the discussions here. Resist the urge to start project-specific mailing lists unless absolutely essential. Have everyone know that the pgFoundry/core distinction only exists for release engineering purposes, and that it can't be allowed to split the community. - Invest in integrating pgFoundry tools into the core distribution. For example, official projects should have makefiles included in the core that'd download and compile the latest compatible version. Components as important as JDBC and some of the procedural languages could be distributed this way. mk ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Table Spaces
> >If you run NTFS, it's still possible to use arbitrary links. In the Windows > >world, they are called junctions. Microsoft does not provide a junction tool > >for some reason (perhaps because it's limited to NTFS). A good tool, free > >and with source, can be found here > >http://www.sysinternals.com/ntw2k/source/misc.shtml#junction > I use this tool myself. Works like a charm. > > We've looked at it before. Apart from anything else I don't think its > license is compatible with PostgreSQL's. The tool was suggested for use as is, not for inclusion in pg source. It can be used to e.g. symlink xlog manually. If you want something in pg source, the relevant lines (about 20) can be copied from MSDN. Andreas ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Call for 7.5 feature completion
> How about this one: Everything we have moved from the core to gborg so > far has been a miserable failure. The code is no longer maintained, or > maintained by three different competing groups, the documentation has > disappeared, the portability is no longer taken care of, and only the > bravest souls even dare look at the stuff. I think before you move > anything more, you need to have a strong, convincing community on the > receiving side rather than just kicking things out and hoping someone > will pick it up. Just because it can be built separately doesn't mean > everything needs to be. Above looks quite true for me too. -- Tatsuo Ishii ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Call for 7.5 feature completion
Joshua D. Drake wrote: > Uhhh?? Are you ripping out all core pls then? plPerlNG is supposed to > replace plPerl, I was talking with Bruce and he seemed to think that > (as long as the code was good enough) that we could incorporate > plPHP??? One reason against including plPHP in the core would be that it would create a circular build dependency between the packages postgresql and php. I think we should rather avoid that. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
