Re: [HACKERS] Binding PostgreSQL to a specific ip address
Note if you are trying to run more than one postgresql you also have to prevent the unix socket files from clashing. > On Wed, 27 Mar 2002, Alastair D'Silva wrote: > > > > > Is there any way to force PostgreSQL to bind to a specific > > IP address? > > > > > > There doesn't seem to be anything about this in the docs, > > and if its > > > not implemented, it would be a useful feature to have (and > > an easy one > > > to implement). > > (from runtime-config.html) > > > >VIRTUAL_HOST (string) > > Specifies the TCP/IP hostname or address on which the > > postmaster is to listen for connections from client > > applications. Defaults to listening on all > > configured addresses > > (including localhost). > > > > Gavin > > > > >---(end of broadcast)--- >TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] contrib/tree/README.tree
Sorry, we don't make a english translate yet. Sorry. It must be done soon. Christopher Kings-Lynne wrote: > This README file to me seems to look like this: > > Was the non-english version committed by mistake? > > Chris > >treequery *> tree[] > > > true, > > , > > > , > > true, > > , > > > > . > > > > > GiST-. > > > 1 > select * from treetbl where treefld > '1.1' and treefld < '1.2'; > select * from treetbl where treefld <* ' > > > ---(end of broadcast)--- > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] > > -- Teodor Sigaev [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] contrib/tree/README.tree
OOps, I don't rememeber we have submitted this module :-) I was intend to do that after writing README in English in 7.2 beta cycle, but after decision it will not go to 7.2 I lost a focus. Oleg On Wed, 27 Mar 2002, Christopher Kings-Lynne wrote: > This README file to me seems to look like this: > > Was the non-english version committed by mistake? > > Chris > >treequery *> tree[] > > > true, > > , > > > , > > true, > > , > > > > . > > > > > GiST-. > > > 1 > select * from treetbl where treefld > '1.1' and treefld < '1.2'; > select * from treetbl where treefld <* ' > > > ---(end of broadcast)--- > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] > Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Mailing List Question
I just sent in this email and it will appear immediately in the list. Somewhat earlier, I have submitted a 25kb patch and then a 5kb gzipped version of that patch to -hackers and -patches - it has not yet appeared on the list. What's going on? Do posts with patches need to be approved or something??? Chris ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] contrib/tree/README.tree
This README file to me seems to look like this: Was the non-english version committed by mistake? Chris treequery *> tree[] true, , , true, , . GiST-. 1 select * from treetbl where treefld > '1.1' and treefld < '1.2'; select * from treetbl where treefld <* ' ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] initdb dies during IpcSemaphoreCreate under BSD jail
"Joel Burton" <[EMAIL PROTECTED]> writes: >> This will allow you to run a single postgres in a single jail only one >> user would have access to it. If you try to run more then one it will >> try to use the same shared memory and crash. > Is this, in fact, the case? Unless BSD jails have very bizarre shared memory behavior, this is nonsense. PG can easily run multiple postmasters in the same machine (there are currently four postmasters of different vintages alive on the machine I'm typing this on). Give each one a different database directory and a unique port number, and you're good to go. It might be that postmasters in different jails on the same machine would have to be assigned different port numbers to keep them from conflicting. Don't know exactly how airtight a BSD jail is ... but there is an interaction between port number and shared memory key. I can imagine that a jail that hides processes but not shared memory segments might confuse our startup logic that tries to detect whether an existing shared memory segment is safe to reuse or not. Perhaps your ISP has seen failures of that type from trying to start multiple postmasters on the same port number in different jails. regards, tom lane ---(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] RI triggers and schemas
Stephan Szabo <[EMAIL PROTECTED]> writes: > The advantage that I see is that we get more control over the time > qualifications used for tuples which may come into play for match > partial. I'm not sure that it's worth the effort to try doing it > this way, but I figured I'd try it. It might be better to address that directly, eg: - define another SnapShot value that has the semantics you want - add a field to Scan plan nodes to specify explicitly the snapshot you want used. Presumably by default the planner would fill this with the standard QuerySnapshot, but you could - find a way to override the default (if nothing else, walk the completed plan tree and tweak the snapshot settings). I believe it's already true that scan plan nodes lock down the target snapshot during plan node startup, by copying QuerySnapshot into node local execution state. So maybe you don't even need the above hack; perhaps just twiddling QuerySnapshot right before ExecutorStart would get the job done. It might be useful to discuss exactly what is bad or broken about the current RI implementation, so we can get a clearer idea of what ought to be done. I know that y'all are dissatisfied with it but I'm not sure I fully understand the issues. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] initdb dies during IpcSemaphoreCreate under BSD jail
> You need to get your provider to set the sysctl jail.sysvipc_allowed to > 1 in the host environment. If they're not willing to do this for you, we > provide this feature on our servers, and also have a shared Postgres > database you can use. My ISP responds to this point: """ >In the thread on the pgsql-hackers list, someone wrote to me to say that >"You need to get your provider to set the sysctl jail.sysvipc_allowed to >1 in the host environment." Apparently, according to this person, this will >allow the use of PG in the jailed environments. Is this something that imeme >can configure? If this isn't clear, I'd be happy to find out more >information for you about this configuration change and what other >ramifications it might have for your servers. This will allow you to run a single postgres in a single jail only one user would have access to it. If you try to run more then one it will try to use the same shared memory and crash. """ Is this, in fact, the case? Thanks! ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] RI triggers and schemas
On Tue, 26 Mar 2002, Jan Wieck wrote: > Tom Lane wrote: > > I think the existing scheme of generating the plan during first use > > in a particular backend is fine. At least as long as we're sticking > > with standard plans at all ... IIRC Stephan was wondering about > > bypassing the whole parse/plan mechanism in favor of heap-access-level > > operations. > > I don't know if using heap-access directly in the RI triggers > is such a good idea. > > It is guaranteed that there is a unique key covering all the > referenced columns (and only them). I'm not sure though if it > has to be in the same column order as the reference. Nor do I > think that matters other than making the creation of the > scankey a bit more difficult. > > But there could be no, some, a full matching index, maybe one > with extra columns at the end on the foreign key. So for the > referential action, the entire process of deciding which > index fits best, pushing some of the qualification into the > index scankey, and do the rest on the heap tuples, has to be > duplicated here. That is the problem that I've run into in working on doing it. I'm still trying to figure out what levels of that code can be used. The advantage that I see is that we get more control over the time qualifications used for tuples which may come into play for match partial. I'm not sure that it's worth the effort to try doing it this way, but I figured I'd try it. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] compile bug in HEAD?
"Nicolas Bazin" <[EMAIL PROTECTED]> writes: > It's more warnings than bugs. I also have seen that but not familiar enough > with bison or yacc to think more of it. Have you got an idea on how to fix > these warnings? ecpg's lexer has always generated those warnings, and so has plpgsql's lexer. AFAICT the sloppy C code is triggered by use of yylineno. Suggest griping to the flex authors. 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] compile bug in HEAD?
Christopher Kings-Lynne wrote: > I don't think this is me... > > gcc -pipe -O -Wall -Wmissing-prototypes -Wmissing-declarations -Wno-error -I > ./../include -I. -I../../../../src/include -DMAJOR_VERSION=2 -DMINOR_VERSIO > N=10 -DPATCHLEVEL=0 -DINCLUDE_PATH=\"/home/chriskl/local/include\" -c -o > pgc.o pgc.c > pgc.c: In function `yylex': > pgc.c:1250: warning: label `find_rule' defined but not used > pgc.l: At top level: > pgc.c:3079: warning: `yy_flex_realloc' defined but not used Yes, I have gotten the same warning for several releases but haven't researched the cause. Patch? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] Fw: pgc.l modif. has been overwritten again
- Original Message -
From: Nicolas
Bazin
To: [EMAIL PROTECTED]
Sent: Wednesday, March 27, 2002 4:03 PM
Subject: pgc.l modif. has been overwritten again
We need a little bit of order when several people
can commit on the source code, It would be nice that they update their local
copy and then commit, or check the directory or check for
conflicts.
It's the second time that this modif has been
overwritten. It's getting anoying.
The patch corrects a test on defines end of
visibility that is performed too early by the preprocessor.
Here it is again.
*** pgc.l Wed Mar 27 15:52:45 2002---
cvs/src/interfaces/ecpg/preproc/pgc.l Fri Feb 15 17:46:57
2002** 859,866
}
<> {- - if
(yy_buffer == NULL) { if ( preproc_tos
> 0 ) {
preproc_tos = 0; --- 859,864
}
<> { if (
preproc_tos > 0 ) {
preproc_tos = 0;
** 866,871
mmerror(PARSE_ERROR, ET_FATAL,
"Missing 'EXEC SQL ENDIF;'");
} yyterminate();
} else--- 864,871
mmerror(PARSE_ERROR, ET_FATAL, "Missing 'EXEC SQL ENDIF;'");
}+ + if (yy_buffer ==
NULL) yyterminate();
else
{** 867,873
mmerror(PARSE_ERROR, ET_FATAL,
"Missing 'EXEC SQL ENDIF;'");
} yyterminate();-
} else
{ struct _yy_buffer
*yb = yy_buffer;--- 867,872
if (yy_buffer == NULL)
yyterminate();
else {
struct _yy_buffer *yb = yy_buffer;
Nicolas.
Re: [HACKERS] compile bug in HEAD?
It's more warnings than bugs. I also have seen that but not familiar enough with bison or yacc to think more of it. Have you got an idea on how to fix these warnings? - Original Message - From: "Christopher Kings-Lynne" <[EMAIL PROTECTED]> To: "Hackers" <[EMAIL PROTECTED]> Sent: Wednesday, March 27, 2002 4:24 PM Subject: [HACKERS] compile bug in HEAD? > I don't think this is me... > > gcc -pipe -O -Wall -Wmissing-prototypes -Wmissing-declarations -Wno-error -I > ./../include -I. -I../../../../src/include -DMAJOR_VERSION=2 -DMINOR_VERSIO > N=10 -DPATCHLEVEL=0 -DINCLUDE_PATH=\"/home/chriskl/local/include\" -c -o > pgc.o pgc.c > pgc.c: In function `yylex': > pgc.c:1250: warning: label `find_rule' defined but not used > pgc.l: At top level: > pgc.c:3079: warning: `yy_flex_realloc' defined but not used > > Chris > > > ---(end of broadcast)--- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html > ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] compile bug in HEAD?
I don't think this is me... gcc -pipe -O -Wall -Wmissing-prototypes -Wmissing-declarations -Wno-error -I ./../include -I. -I../../../../src/include -DMAJOR_VERSION=2 -DMINOR_VERSIO N=10 -DPATCHLEVEL=0 -DINCLUDE_PATH=\"/home/chriskl/local/include\" -c -o pgc.o pgc.c pgc.c: In function `yylex': pgc.c:1250: warning: label `find_rule' defined but not used pgc.l: At top level: pgc.c:3079: warning: `yy_flex_realloc' defined but not used Chris ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] RI triggers and schemas
> > Tom Lane wrote: > >> An advantage of using OIDs is that we could forget the pushups that > >> ALTER TABLE RENAME presently goes through to update RI triggers. > > > I'm always suspicious about the spec if it makes RENAME easy. > > Point taken ;-) I don't get it??? Chris ---(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] Binding PostgreSQL to a specific ip address
Cheers, next time I'll look a bit harder :) -- Alastair D'Silva B. Sc.mob: 0413 485 733 Networking Consultant New Millennium Networking http://www.newmillennium.net.au > -Original Message- > From: Gavin Sherry [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, 27 March 2002 3:46 PM > To: Alastair D'Silva > Cc: [EMAIL PROTECTED] > Subject: Re: [HACKERS] Binding PostgreSQL to a specific ip address > > > On Wed, 27 Mar 2002, Alastair D'Silva wrote: > > > Is there any way to force PostgreSQL to bind to a specific > IP address? > > > > There doesn't seem to be anything about this in the docs, > and if its > > not implemented, it would be a useful feature to have (and > an easy one > > to implement). > (from runtime-config.html) > >VIRTUAL_HOST (string) > Specifies the TCP/IP hostname or address on which the > postmaster is to listen for connections from client > applications. Defaults to listening on all > configured addresses > (including localhost). > > Gavin > ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Binding PostgreSQL to a specific ip address
On Wed, 27 Mar 2002, Alastair D'Silva wrote: > Is there any way to force PostgreSQL to bind to a specific IP address? > > There doesn't seem to be anything about this in the docs, and if its not > implemented, it would be a useful feature to have (and an easy one to > implement). (from runtime-config.html) VIRTUAL_HOST (string) Specifies the TCP/IP hostname or address on which the postmaster is to listen for connections from client applications. Defaults to listening on all configured addresses (including localhost). Gavin ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Binding PostgreSQL to a specific ip address
Is there any way to force PostgreSQL to bind to a specific IP address? There doesn't seem to be anything about this in the docs, and if its not implemented, it would be a useful feature to have (and an easy one to implement). -- Alastair D'Silva B. Sc.mob: 0413 485 733 Networking Consultant New Millennium Networking http://www.newmillennium.net.au ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] RI triggers and schemas
Hiroshi Inoue <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> An advantage of using OIDs is that we could forget the pushups that >> ALTER TABLE RENAME presently goes through to update RI triggers. > I'm always suspicious about the spec if it makes RENAME easy. Point taken ;-) However, unless someone can give a specific reason to make life hard, I'm inclined to simplify this. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] initdb dies during IpcSemaphoreCreate under BSD jail
> -Original Message- > From: Alastair D'Silva [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, March 26, 2002 10:52 PM > To: 'Vince Vielhaber'; 'Joel Burton' > Cc: [EMAIL PROTECTED] > Subject: RE: [HACKERS] initdb dies during IpcSemaphoreCreate under BSD > jail > > > You need to get your provider to set the sysctl jail.sysvipc_allowed to > 1 in the host environment. If they're not willing to do this for you, we > provide this feature on our servers, and also have a shared Postgres > database you can use. Thanks for the tip. I'm not a *BSD guru, so I'm not familiar with this configuration change, but I've written to the Powers That Be at my ISP to see if this is something that they feel they could change. ---(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] Rolling v7.2.1 ...
Peter Eisentraut wrote: > Bruce Momjian writes: > > > I can do it hear easily. Let me know and I will give you the URL. It > > takes only 7 minutes here. > > Go ahead. Just make sure you use some reasonably recent style sheets (>= > 1.70) and not 1.64 that you currently have. I will not be able to upgrade the style sheets for a day. I remember sgml install as being quite complicated. Can you give me the URL for the new style sheets? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] initdb dies during IpcSemaphoreCreate under BSD jail
You need to get your provider to set the sysctl jail.sysvipc_allowed to 1 in the host environment. If they're not willing to do this for you, we provide this feature on our servers, and also have a shared Postgres database you can use. -- Alastair D'Silva B. Sc.mob: 0413 485 733 Networking Consultant New Millennium Networking http://www.newmillennium.net.au > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] On Behalf Of > Vince Vielhaber > Sent: Tuesday, 26 March 2002 3:03 AM > To: Joel Burton > Cc: [EMAIL PROTECTED] > Subject: Re: [HACKERS] initdb dies during IpcSemaphoreCreate > under BSD jail > > > On Mon, 25 Mar 2002, Joel Burton wrote: > > > (posted last week to pgsql-general; no responses there, so > I'm seeing > > if anyone here can contribute. Thanks!) > > > > > > I'm working on a site hosted in a BSD Jail; they have MySQL > installed > > but, of course, I'd rather use PostgreSQL. > > > > It installs fine but can't initdb; get the following: > > > > Fixing permissions on existing directory > /usr/local/pgsql/data... ok > > creating directory /usr/local/pgsql/data/base... ok > creating directory > > /usr/local/pgsql/data/global... ok creating directory > > /usr/local/pgsql/data/pg_xlog... ok creating directory > > /usr/local/pgsql/data/pg_clog... ok creating template1 database in > > /usr/local/pgsql/data/base/1... > > IpcSemaphoreCreate: semget(key=1, num=17, 03600) failed: > Function not > > implemented > > > > Earlier message traffic suggests that SYSV IPC has not been > fixed to > > run under BSD Jails. > > > > The last time this was raised was ~1 year ago. Has there been any > > changes here that anyone knows of? Any hope of getting PG > running in > > our jail? (Or, alternatively, can PG run on the real machine's > > processes so that the different jails can access it?) > > I don't know about running PG in a jail, but if you have it > running on the parent or real machine the jails can access it > just fine but not as localhost. > > Vince. > -- > == > > Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED] http://www.pop4.net 56K Nationwide Dialup from $16.00/mo at Pop4 Networking Online Campground Directoryhttp://www.camping-usa.com Online Giftshop Superstorehttp://www.cloudninegifts.com == ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] RI triggers and schemas
Tom Lane wrote: > > As of CVS tip, referential integrity triggers are kinda broken: they > will only work for tablenames that are in the current search path. > I think that instead of storing just table names in the trigger > parameters, we should store either table OIDs or schema name + table > name. Do you have any preferences about this? > > An advantage of using OIDs is that we could forget the pushups that > ALTER TABLE RENAME presently goes through to update RI triggers. I'm always suspicious about the spec if it makes RENAME easy. regards, Hiroshi Inoue ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Rolling v7.2.1 ...
Bruce Momjian writes: > I can do it hear easily. Let me know and I will give you the URL. It > takes only 7 minutes here. Go ahead. Just make sure you use some reasonably recent style sheets (>= 1.70) and not 1.64 that you currently have. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Rolling v7.2.1 ...
El Mar 26, Peter Eisentraut escribio: > Marc G. Fournier writes: > > should there be a step in the 'build dist' > > that builds the docs based on the sgml? > > I've been promoting that every time this problem happens. And the problem > does happen every time we're making a minor release. I think it's about > time to clean this up. But it won't happen in the 7.2 branch anymore. Hello all: I've been trying to generate HTML from the SGML source here in Mandrake Linux 8.1, and it needs some patching (Mdk Linux puts collateindex.pl in /usr/bin rather that $DOCBOOKSTYLE/bin). I posted to pgsql-patches a one-liner that fixed a small problem, and later a patch to allow discovery of collateindex.pl, but the moderator apparently didn't bother to approve the second post. This still needs an autoconf macro to allow manpage building, 'cause docbook2man-spec.pl lives somewhere else than the Makefile expects. (Yes, I know I can set D2MDIR and DOCBOOKINDEX, but I think this is cleaner) This is the output of cvs diff -u config/docbook.m4 src/Makefile.global.in Index: config/docbook.m4 === RCS file: /projects/cvsroot/pgsql/config/docbook.m4,v retrieving revision 1.1 diff -u -r1.1 docbook.m4 --- config/docbook.m4 2000/11/05 21:04:06 1.1 +++ config/docbook.m4 2002/03/27 02:51:27 @@ -57,7 +57,8 @@ for pgac_postfix in \ sgml/stylesheets/nwalsh-modular \ sgml/stylesheets/docbook \ -sgml/docbook/dsssl/modular +sgml/docbook/dsssl/modular \ +sgml/docbook/dsssl-stylesheets do pgac_candidate=$pgac_prefix/$pgac_infix/$pgac_postfix if test -r "$pgac_candidate/html/docbook.dsl" \ @@ -77,3 +78,26 @@ else AC_MSG_RESULT(no) fi])# PGAC_PATH_DOCBOOK_STYLESHEETS + +# PGAC_PATH_DOCBOOK_COLLATEINDEX +# -- +AC_DEFUN([PGAC_PATH_DOCBOOK_COLLATEINDEX], +[AC_MSG_CHECKING([for collateindex.pl]) +AC_CACHE_VAL([pgac_cv_path_collateindex], +[if test -n "$DOCBOOKINDEX"; then + pgac_cv_path_collateindex=$DOCBOOKINDEX +else + for pgac_prefix in $DOCBOOKSTYLE/bin /usr/bin; do +if test -x "$pgac_prefix/collateindex.pl"; then + pgac_cv_path_collateindex=$pgac_prefix/collateindex.pl + break +fi + done +fi]) +DOCBOOKINDEX=$pgac_cv_path_collateindex +AC_SUBST([DOCBOOKINDEX]) +if test -n "$DOCBOOKINDEX"; then + AC_MSG_RESULT([$DOCBOOKINDEX]) +else + AC_MSG_RESULT(no) +fi])# PGAC_PATH_DOCBOOK_COLLATEINDEX Index: src/Makefile.global.in === RCS file: /projects/cvsroot/pgsql/src/Makefile.global.in,v retrieving revision 1.143 diff -u -r1.143 Makefile.global.in --- src/Makefile.global.in 2002/03/13 00:05:02 1.143 +++ src/Makefile.global.in 2002/03/27 02:51:28 @@ -149,6 +149,7 @@ have_docbook = @have_docbook@ DOCBOOKSTYLE = @DOCBOOKSTYLE@ +DOCBOOKINDEX = @DOCBOOKINDEX@ ## -- Alvaro Herrera () "La primera ley de las demostraciones en vivo es: no trate de usar el sistema. Escriba un guión que no toque nada para no causar daños." (Jakob Nielsen) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Rolling v7.2.1 ...
Peter Eisentraut wrote: > Marc G. Fournier writes: > > > good point ... but, where should I be pulling from? ~ftp/pub/doc/7.2 > > contains .pdf files, which I didn't think we wanted to put into the > > distribution ... is there an alternative place I should be pulling docs > > >from then ~ftp/pub/dev/doc? > > No, there currently is no place where these docs are built, because this > is the first time we're releasing from this branch. I've been trying all > day to build them on postgresql.org, but that machine seems to be > incredibly slow right now. I'll try again later. I can do it hear easily. Let me know and I will give you the URL. It takes only 7 minutes here. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Rolling v7.2.1 ...
Marc G. Fournier writes: > good point ... but, where should I be pulling from? ~ftp/pub/doc/7.2 > contains .pdf files, which I didn't think we wanted to put into the > distribution ... is there an alternative place I should be pulling docs > >from then ~ftp/pub/dev/doc? No, there currently is no place where these docs are built, because this is the first time we're releasing from this branch. I've been trying all day to build them on postgresql.org, but that machine seems to be incredibly slow right now. I'll try again later. > should there be a step in the 'build dist' > that builds the docs based on the sgml? I've been promoting that every time this problem happens. And the problem does happen every time we're making a minor release. I think it's about time to clean this up. But it won't happen in the 7.2 branch anymore. -- Peter Eisentraut [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] Autoconf upgrade
There's no such thing as stable ports - there is only HEAD... Chris > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Peter Eisentraut > Sent: Wednesday, 27 March 2002 2:14 AM > To: Marc G. Fournier > Cc: PostgreSQL Development > Subject: Re: [HACKERS] Autoconf upgrade > > > Marc G. Fournier writes: > > > %autoconf --version > > autoconf (GNU Autoconf) 2.52 > > FreeBSD HEAD has 2.53 in ports. Not sure if you can pull that in if > you're following stable. > > -- > Peter Eisentraut [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 > ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] build of 7.2.1 on SCO Openserver and Unixware 7.1.1
Bruce,
The reason to move the socket library is that during configuration script
execution, the binary created core dumps if not in the order I gave. You can
check in the port list, some people have been complaining that they could
not even go any further than the configure step and that is the reason.
Here is the message you get otherwise:
checking test program... failed
configure: error:
*** Could not execute a simple test program. This may be a problem
*** related to locating shared libraries. Check the file 'config.log'
*** for the exact reason.
In config.log the last lines are:
configure:7516: checking test program
configure:7525: gcc -o conftest -O2
conftest.c -lz -lPW -lgen -lld -lnsl -lsocket -ldl -lm -lreadline -ltermcap
1>&5
configure: failed program was:
#line 7521 "configure"
#include "confdefs.h"
int main() { return 0; }
pow is in the static library libm and SCO Openserver linker does not accept
to link it in a so file. The modification I provide works whithout changing
the way the code works. If there is another way to get libm linked in so
Here is the message I get:
gcc -shared -Wl,-z,text -Wl,-h,libpsqlodbc.so.0 -Wl,-Bsymbolic info.o bind.o
columninfo.o connection.o convert.o drvconn.o environ.o execute.o lobj.o
md5.o misc.o options.o pgtypes.o psqlodbc.o qresult.o results.o socket.o
parse.o statement.o tuple.o tuplelist.o dlg_specific.o odbcapi.o
pps.o -lsocket -lnsl -lm -o libpsqlodbc.so.0.27
relocations referenced
from file(s)
/usr/ccs/lib/libm.a(pow.o)
/usr/ccs/lib/libm.a(fmod.o)
/usr/ccs/lib/libm.a(merr.o)
fatal error: relocations remain against allocatable but non-writable
section: .text
collect2: ld returned 1 exit status
The TCL stuff is because Caldera distribution of TCL is compiled with their
compiler. If you happen to use another compiler on your platform (gcc) it
doesn't work anymore. Caldera compiler has -belf -Kpic options which are
fully incompatible with gcc. That's why I though best to leave the TCL
packages been compiled with the compiler used for postgresql.
Note that I have the same issue for perl modules, but I haven't found a
proper way to correct the make files automatically generated. I understand
that we would want the same compilation options but if you install TCL or
PERL from packages you may not have the same compiler.
Appart these points the regression tests work fine for these platforms. They
are still a few warnings during the compilation process, when I get some
time, I'll try to correct them.
Nicolas
- Original Message -
From: "Bruce Momjian" <[EMAIL PROTECTED]>
To: "Nicolas Bazin" <[EMAIL PROTECTED]>
Cc: "PostgreSQL-development" <[EMAIL PROTECTED]>
Sent: Wednesday, March 27, 2002 12:08 AM
Subject: Re: [HACKERS] build of 7.2.1 on SCO Openserver and Unixware 7.1.1
>
> We am going to need an explaination on these changes. Why move
> the socket test? Why change pow()? The TCL stuff is going to
> effect other platforms and probably will not be applied without a
> good reason.
>
> --
-
>
> Nicolas Bazin wrote:
> > Sorry for the package, but the following patch need to be applied
> > to get the new verion compiled on SCO Openserver 5.0.5 and
> > Unixware 7.1.1
>
> [ Attachment, skipping... ]
>
> >
> > ---(end of broadcast)---
> > TIP 5: Have you checked our extensive FAQ?
> >
> > http://www.postgresql.org/users-lounge/docs/faq.html
>
> --
> Bruce Momjian| http://candle.pha.pa.us
> [EMAIL PROTECTED] | (610) 853-3000
> + If your life is a hard drive, | 830 Blythe Avenue
> + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
>
> ---(end of broadcast)---
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html
>
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] RI triggers and schemas
Tom Lane wrote: > Jan Wieck <[EMAIL PROTECTED]> writes: > > Actually I'm kicking around a slightly different idea, how to > > resolve the entire problem. We could build up the > > querystring, required to do the check, at trigger creation > > time, parse it and store the querytree node-print or hand it > > to the trigger as argument. > > Hm. Seems kinda bulky; and the parse step alone is not that expensive. > (You could only do raw grammar parsing I think, not the parse analysis > phase, unless you wanted to deal with having to outdate these stored > querytrees after changes in table schemas.) You're right, as soon as other details than the column or table name might change, this could get even more screwed. > I think the existing scheme of generating the plan during first use > in a particular backend is fine. At least as long as we're sticking > with standard plans at all ... IIRC Stephan was wondering about > bypassing the whole parse/plan mechanism in favor of heap-access-level > operations. I don't know if using heap-access directly in the RI triggers is such a good idea. It is guaranteed that there is a unique key covering all the referenced columns (and only them). I'm not sure though if it has to be in the same column order as the reference. Nor do I think that matters other than making the creation of the scankey a bit more difficult. But there could be no, some, a full matching index, maybe one with extra columns at the end on the foreign key. So for the referential action, the entire process of deciding which index fits best, pushing some of the qualification into the index scankey, and do the rest on the heap tuples, has to be duplicated here. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] RI triggers and schemas
Jan Wieck <[EMAIL PROTECTED]> writes: > Actually I'm kicking around a slightly different idea, how to > resolve the entire problem. We could build up the > querystring, required to do the check, at trigger creation > time, parse it and store the querytree node-print or hand it > to the trigger as argument. Hm. Seems kinda bulky; and the parse step alone is not that expensive. (You could only do raw grammar parsing I think, not the parse analysis phase, unless you wanted to deal with having to outdate these stored querytrees after changes in table schemas.) I think the existing scheme of generating the plan during first use in a particular backend is fine. At least as long as we're sticking with standard plans at all ... IIRC Stephan was wondering about bypassing the whole parse/plan mechanism in favor of heap-access-level operations. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] RI triggers and schemas
On Tue, 26 Mar 2002, Tom Lane wrote: > As of CVS tip, referential integrity triggers are kinda broken: they > will only work for tablenames that are in the current search path. > I think that instead of storing just table names in the trigger > parameters, we should store either table OIDs or schema name + table > name. Do you have any preferences about this? > > An advantage of using OIDs is that we could forget the pushups that > ALTER TABLE RENAME presently goes through to update RI triggers. > > On the other hand, as long as the RI implementation depends on > generating textual queries, it'd be faster to have the names available > than to have to look them up from the OID. But I seem to recall Stephan > threatening to rewrite that code at a lower level pretty soon, so the > speed issue might go away. In any case it's probably a minor issue > compared to generating the query plan. > > So I'm leaning towards OIDs, but wanted to see if anyone had a beef > with that. I'd say oids are better (and probably attnos for the columns). That's generally what I've been assuming in my attempts on rewriting the code. I've been working on getting something together using the heap_*/index_* scanning functions. I feel like I'm reimplementing alot of wheels though, so I need to see what I can use from other places. ---(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] RI triggers and schemas
Tom Lane wrote: > As of CVS tip, referential integrity triggers are kinda broken: they > will only work for tablenames that are in the current search path. > I think that instead of storing just table names in the trigger > parameters, we should store either table OIDs or schema name + table > name. Do you have any preferences about this? > > An advantage of using OIDs is that we could forget the pushups that > ALTER TABLE RENAME presently goes through to update RI triggers. > > On the other hand, as long as the RI implementation depends on > generating textual queries, it'd be faster to have the names available > than to have to look them up from the OID. But I seem to recall Stephan > threatening to rewrite that code at a lower level pretty soon, so the > speed issue might go away. In any case it's probably a minor issue > compared to generating the query plan. > > So I'm leaning towards OIDs, but wanted to see if anyone had a beef > with that. I'd go with OIDs too, because they're unambigous and don't change. Actually I'm kicking around a slightly different idea, how to resolve the entire problem. We could build up the querystring, required to do the check, at trigger creation time, parse it and store the querytree node-print or hand it to the trigger as argument. Isn't that using oid's already, ignoring the names? This requires a shortcut into SPI to plan an existing parsetree. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Indexes, TOAST tables, and namespaces
I'm trying to work out what to do with indexes in the context of schemas. As of today's CVS tip, what the code does is that CREATE INDEX can only specify an unqualified index name, and the index is automatically created in the same namespace as its parent table. Thus, index names still have to be distinct from each other and from regular table names, but only within a namespace (schema) not globally over the whole database. I seem to recall someone claiming that the SQL spec requires indexes to be in a different namespace from tables --- ie, index names and table names should never conflict, period. I can't find any evidence of this in the spec; AFAICT it doesn't mention the concept of indexes at all. But perhaps this is standard industry practice (what do Oracle and other DBMSes do?). We could imagine creating an "auxiliary namespace" for each regular namespace in which to put indexes, if anyone thinks that's worthwhile. Thoughts? In any case, I intend to remove the current prohibition against user table names starting with "pg_". Instead there will be a prohibition against user schema names starting with "pg_"; but within a user schema you can call your tables whatever you like. The existing protection restrictions associated with IsSystemRelationName() calls will migrate over to instead be tests on which namespace contains the table in question. The system catalogs will still be named pg_xxx, but will live in namespace "pg_catalog"; TOAST tables will still be named "pg_toast_xxx", but will live in namespace "pg_toast". This should minimize the disruption to client applications that look at the catalogs. There'll also be temporary namespaces "pg_temp_xxx" to house temporary tables. Comments, objections, better ideas? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] RI triggers and schemas
As of CVS tip, referential integrity triggers are kinda broken: they will only work for tablenames that are in the current search path. I think that instead of storing just table names in the trigger parameters, we should store either table OIDs or schema name + table name. Do you have any preferences about this? An advantage of using OIDs is that we could forget the pushups that ALTER TABLE RENAME presently goes through to update RI triggers. On the other hand, as long as the RI implementation depends on generating textual queries, it'd be faster to have the names available than to have to look them up from the OID. But I seem to recall Stephan threatening to rewrite that code at a lower level pretty soon, so the speed issue might go away. In any case it's probably a minor issue compared to generating the query plan. So I'm leaning towards OIDs, but wanted to see if anyone had a beef with that. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Autoconf upgrade
On Tue, 26 Mar 2002 13:13:58 -0500 (EST) Peter Eisentraut <[EMAIL PROTECTED]> wrote: > Marc G. Fournier writes: > > > %autoconf --version > > autoconf (GNU Autoconf) 2.52 > > FreeBSD HEAD has 2.53 in ports. Not sure if you can pull that in if > you're following stable. > > -- > Peter Eisentraut [EMAIL PROTECTED] Hi, The FreeBSD ports tree only has one "branch" and that is the head. There is no stable or current branch. When you pull the ports tree you get whatever is there. It is up to the port to figure out which version of FreeBSD you have, as is evidenced by the massive breakage right now on current for alot of ports. GB -- GB Clark II | Roaming FreeBSD Admin [EMAIL PROTECTED] | General Geek CTHULU for President - Why choose the lesser of two evils? ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Autoconf upgrade
Easily, just pointing out that we are already at 2.52 on the main server ... just upgraded it on the 12th, will work on upgrading it over the next day or so, since I'm in the middle of dealing with preparations for a security audit at the University *oh joy* ... :) On Tue, 26 Mar 2002, Peter Eisentraut wrote: > Marc G. Fournier writes: > > > %autoconf --version > > autoconf (GNU Autoconf) 2.52 > > FreeBSD HEAD has 2.53 in ports. Not sure if you can pull that in if > you're following stable. > > -- > Peter Eisentraut [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] Autoconf upgrade
Marc G. Fournier writes: > %autoconf --version > autoconf (GNU Autoconf) 2.52 FreeBSD HEAD has 2.53 in ports. Not sure if you can pull that in if you're following stable. -- Peter Eisentraut [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] Autoconf upgrade
%autoconf --version autoconf (GNU Autoconf) 2.52 Written by David J. MacKenzie. Copyright 1992, 1993, 1994, 1996, 1999, 2000, 2001 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. %uname -a FreeBSD postgresql.org 4.5-STABLE FreeBSD 4.5-STABLE #1: Tue Mar 12 08:30:14 CST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/kernel i386 On Mon, 11 Mar 2002, Peter Eisentraut wrote: > Thomas Lockhart writes: > > > Hmm. I'd much rather be using a version which actually ships with some > > distros. I've got 2.13 on my rather fresh Linux box. Anyone else getting > > something later any time soon? > > Autoconf 2.13 is probably going to stay around for quite a while since a > lot of projects are using it. But it's dead and old (>2 years). > > We could argue about using 2.52 or 2.53. 2.52 is widely adopted, but if > we're going to switch, why not use the latest stable release? We are > quite known for scolding people for using old releases of the software > that we maintain. > > -- > Peter Eisentraut [EMAIL PROTECTED] > > > ---(end of broadcast)--- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org > ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Configuring for 64-bit integer date/time storage?
Thomas Lockhart writes: > Did you catch the questions on dealing with HAVE_LONG_INT_64, > HAVE_LONG_LONG_INT_64, and INT64_IS_BUSTED? I'd like to be able to > enable/disable integer date/time storage in configure, so some notion of > "do I have some kind of 64 bit integer?" seems to be desirable in > configure itself. Is this what you want? if test "$enable_integer_datetimes" = yes; then if test "$HAVE_LONG_LONG_INT64" != yes && test "$HAVE_LONG_INT64" != yes; then AC_MSG_ERROR([integer datetimes not available due to lack of 64-bit integer type]) fi fi -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Autoconf upgrade
> I plan to upgrade to Autoconf 2.53 in the next couple of days. If anyone > has configure changes pending or other objections, speak now. I'm working on the integer timestamp issue, which seems to have an autoconf component. I was hoping for feedback on the question of setting HAVE_LONG_INT_64, HAVE_LONG_LONG_INT_64, and INT64_IS_BUSTED, how that relates to USE_INTEGER_DATETIMES, and how much of this to push into autoconf. istm that most of it needs to be in autoconf so that we get these defined consistantly. - Thomas ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Autoconf upgrade
I plan to upgrade to Autoconf 2.53 in the next couple of days. If anyone has configure changes pending or other objections, speak now. An RPM package for Autoconf 2.53 is available at http://www.postgresql.org/~petere/download/ You might wish to use this until your vendor comes out with one. -- Peter Eisentraut [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
[HACKERS] Contrib update
Hi Justin, I have a new updated version of the Ora2Pg tool which correct many problems and add some new features, could you or someone else update the contrib directory. (download at: http://www.samse.fr/GPL/ora2pg/ora2pg-1.8.tar.gz) I also just post a new tool in replacement of the Oracle XSQL Servlet, use to create dynamic web application with XML/XSLT. Let me know if it can take place under the contrib directory. (http://www.samse.fr/GPL/pxsql/) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Rolling v7.2.1 ...
"Marc G. Fournier" <[EMAIL PROTECTED]> writes: > should there be a step in the 'build dist' > that builds the docs based on the sgml? It would be a good idea to rebuild the 7.2 docs from 7.2.1 sources, as we made several important fixes in the documentation since 7.2 release. I dunno whether it's worth trying to make it fully automatic right at the moment, though. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Rolling v7.2.1 ...
good point ... but, where should I be pulling from? ~ftp/pub/doc/7.2 contains .pdf files, which I didn't think we wanted to put into the distribution ... is there an alternative place I should be pulling docs from then ~ftp/pub/dev/doc? should there be a step in the 'build dist' that builds the docs based on the sgml? On Mon, 25 Mar 2002, Peter Eisentraut wrote: > Marc G. Fournier writes: > > > Try her out and let me know if there are any problems ... the build looks > > clean, sizes all look right ... > > ... but the contained documentation is for 7.3. > > -- > Peter Eisentraut [EMAIL PROTECTED] > > ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] build of 7.2.1 on SCO Openserver and Unixware 7.1.1
We am going to need an explaination on these changes. Why move the socket test? Why change pow()? The TCL stuff is going to effect other platforms and probably will not be applied without a good reason. --- Nicolas Bazin wrote: > Sorry for the package, but the following patch need to be applied > to get the new verion compiled on SCO Openserver 5.0.5 and > Unixware 7.1.1 [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
