Re: [PATCHES] make installcheck on non-default ports
Tom Lane wrote: I think there is something wrong with your setup procedures, because I've never needed such. (I've corresponded with Joe off-list about this --- maybe we can produce a FAQ about the right way to do it once the dust settles.) Yup, got it. AFAICS this would defeat the documented behavior of being able to set PGHOST/PGPORT in the environment to control which postmaster "make installcheck" will speak to. So, yeah, I think it's a bad idea. OK. I'll see about playing with the scripts you sent me. Thanks, Joe ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] make installcheck on non-default ports
Joe Conway <[EMAIL PROTECTED]> writes: > I was trying to set up my dev box for multiple simultaneous Postgres > installs (7.3 stable, 7.4 stable, cvs head) and discovered that > `make installcheck` did not honor the default port assigned at configure > time. I view this as a bug. I think there is something wrong with your setup procedures, because I've never needed such. (I've corresponded with Joe off-list about this --- maybe we can produce a FAQ about the right way to do it once the dust settles.) > Any objections to me applying this to cvs head? AFAICS this would defeat the documented behavior of being able to set PGHOST/PGPORT in the environment to control which postmaster "make installcheck" will speak to. So, yeah, I think it's a bad idea. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] make installcheck on non-default ports
Joe Conway wrote: I was trying to set up my dev box for multiple simultaneous Postgres installs (7.3 stable, 7.4 stable, cvs head) and discovered that `make installcheck` did not honor the default port assigned at configure time. I view this as a bug. The attached resolves the issue for all three versions. Any objections to me applying this to cvs head? What about 7.3 and 7.4 stable branches? BTW, a similar change is needed in contrib/contrib-global.mk so that `make installcheck` will work for contrib. New patch attached. Joe Index: contrib/contrib-global.mk === RCS file: /cvsroot/pgsql-server/contrib/contrib-global.mk,v retrieving revision 1.5 diff -c -r1.5 contrib-global.mk *** contrib/contrib-global.mk 2 Nov 2002 00:16:21 - 1.5 --- contrib/contrib-global.mk 26 Nov 2003 04:42:55 - *** *** 209,215 # against installed postmaster installcheck: submake ! $(top_builddir)/src/test/regress/pg_regress $(REGRESS) # in-tree test doesn't work yet (no way to install my shared library) #check: all submake --- 209,215 # against installed postmaster installcheck: submake ! $(top_builddir)/src/test/regress/pg_regress --port=$(DEF_PGPORT) $(REGRESS) # in-tree test doesn't work yet (no way to install my shared library) #check: all submake Index: src/test/regress/GNUmakefile === RCS file: /cvsroot/pgsql-server/src/test/regress/GNUmakefile,v retrieving revision 1.43 diff -c -r1.43 GNUmakefile *** src/test/regress/GNUmakefile2 Nov 2003 21:56:15 - 1.43 --- src/test/regress/GNUmakefile26 Nov 2003 04:00:38 - *** *** 122,128 $(SHELL) ./pg_regress --temp-install --top-builddir=$(top_builddir) --schedule=$(srcdir)/parallel_schedule --multibyte=$(MULTIBYTE) $(MAXCONNOPT) installcheck: all ! $(SHELL) ./pg_regress --schedule=$(srcdir)/serial_schedule --multibyte=$(MULTIBYTE) # old interfaces follow... --- 122,128 $(SHELL) ./pg_regress --temp-install --top-builddir=$(top_builddir) --schedule=$(srcdir)/parallel_schedule --multibyte=$(MULTIBYTE) $(MAXCONNOPT) installcheck: all ! $(SHELL) ./pg_regress --port=$(DEF_PGPORT) --schedule=$(srcdir)/serial_schedule --multibyte=$(MULTIBYTE) # old interfaces follow... *** *** 131,137 runtest: installcheck bigtest: ! $(SHELL) ./pg_regress --schedule=$(srcdir)/serial_schedule --multibyte=$(MULTIBYTE) numeric_big bigcheck: $(SHELL) ./pg_regress --temp-install --top-builddir=$(top_builddir) --schedule=$(srcdir)/parallel_schedule --multibyte=$(MULTIBYTE) $(MAXCONNOPT) numeric_big --- 131,137 runtest: installcheck bigtest: ! $(SHELL) ./pg_regress --port=$(DEF_PGPORT) --schedule=$(srcdir)/serial_schedule --multibyte=$(MULTIBYTE) numeric_big bigcheck: $(SHELL) ./pg_regress --temp-install --top-builddir=$(top_builddir) --schedule=$(srcdir)/parallel_schedule --multibyte=$(MULTIBYTE) $(MAXCONNOPT) numeric_big ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[PATCHES] make installcheck on non-default ports
I was trying to set up my dev box for multiple simultaneous Postgres installs (7.3 stable, 7.4 stable, cvs head) and discovered that `make installcheck` did not honor the default port assigned at configure time. I view this as a bug. The attached resolves the issue for all three versions. Any objections to me applying this to cvs head? What about 7.3 and 7.4 stable branches? Thanks, Joe Index: src/test/regress/GNUmakefile === RCS file: /cvsroot/pgsql-server/src/test/regress/GNUmakefile,v retrieving revision 1.43 diff -c -r1.43 GNUmakefile *** src/test/regress/GNUmakefile2 Nov 2003 21:56:15 - 1.43 --- src/test/regress/GNUmakefile26 Nov 2003 04:00:38 - *** *** 122,128 $(SHELL) ./pg_regress --temp-install --top-builddir=$(top_builddir) --schedule=$(srcdir)/parallel_schedule --multibyte=$(MULTIBYTE) $(MAXCONNOPT) installcheck: all ! $(SHELL) ./pg_regress --schedule=$(srcdir)/serial_schedule --multibyte=$(MULTIBYTE) # old interfaces follow... --- 122,128 $(SHELL) ./pg_regress --temp-install --top-builddir=$(top_builddir) --schedule=$(srcdir)/parallel_schedule --multibyte=$(MULTIBYTE) $(MAXCONNOPT) installcheck: all ! $(SHELL) ./pg_regress --port=$(DEF_PGPORT) --schedule=$(srcdir)/serial_schedule --multibyte=$(MULTIBYTE) # old interfaces follow... *** *** 131,137 runtest: installcheck bigtest: ! $(SHELL) ./pg_regress --schedule=$(srcdir)/serial_schedule --multibyte=$(MULTIBYTE) numeric_big bigcheck: $(SHELL) ./pg_regress --temp-install --top-builddir=$(top_builddir) --schedule=$(srcdir)/parallel_schedule --multibyte=$(MULTIBYTE) $(MAXCONNOPT) numeric_big --- 131,137 runtest: installcheck bigtest: ! $(SHELL) ./pg_regress --port=$(DEF_PGPORT) --schedule=$(srcdir)/serial_schedule --multibyte=$(MULTIBYTE) numeric_big bigcheck: $(SHELL) ./pg_regress --temp-install --top-builddir=$(top_builddir) --schedule=$(srcdir)/parallel_schedule --multibyte=$(MULTIBYTE) $(MAXCONNOPT) numeric_big ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] minor cleanup in plpgsql.sgml
The reported correction was removing the superfluous full_name varchar (which
Neil Conway also reported a few days back). When i was rewriting the
function, I subconsciously switched the SELECT INTO statement to the (IMHO)
more legible syntax, though nothing was wrong with the previous version of
that statement.
Robert Treat
On Tuesday 25 November 2003 20:30, Christopher Kings-Lynne wrote:
> Ummm - surely the original was correct?
>
> Chris
>
> Robert Treat wrote:
> > Marcos Truchado <[EMAIL PROTECTED]> reported this on -docs
> > yesterday.
> >
> > Robert Treat
> >
> >
> >
> >
> > Index: plpgsql.sgml
> > ===
> > RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/plpgsql.sgml,v
> > retrieving revision 1.29
> > diff -c -r1.29 plpgsql.sgml
> > *** plpgsql.sgml12 Nov 2003 22:47:47 - 1.29
> > --- plpgsql.sgml25 Nov 2003 14:12:50 -
> > ***
> > *** 986,994
> >
> > DECLARE
> > users_rec RECORD;
> > - full_name varchar;
> > BEGIN
> > ! SELECT INTO users_rec * FROM users WHERE user_id=3;
> >
> > IF users_rec.homepage IS NULL THEN
> > -- user entered no homepage, return "http://";
> > --- 986,993
> >
> > DECLARE
> > users_rec RECORD;
> > BEGIN
> > ! SELECT * FROM users WHERE user_id=3 INTO users_rec;
> >
> > IF users_rec.homepage IS NULL THEN
> > -- user entered no homepage, return "http://";
> >
> >
> >
> >
> >
> > ---(end of broadcast)---
> > TIP 4: Don't 'kill -9' the postmaster
>
> ---(end of broadcast)---
> TIP 5: Have you checked our extensive FAQ?
>
>http://www.postgresql.org/docs/faqs/FAQ.html
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] Bug in fd.c (FreeFile)
Nope. My bad. My head has an off by one error. Drop the first part of the patch, but the second part could be retained. Very minor. Off to hide in shame, Claudio > -Original Message- > From: Claudio Natoli [mailto:[EMAIL PROTECTED] > Sent: Wednesday, 26 November 2003 12:34 PM > To: [EMAIL PROTECTED] > Subject: [PATCHES] Bug in fd.c (FreeFile) > > > > I believe FreeFile has an "off by one" type error. Apart from possibly > accessing past the end of the array, when combined with the > while loop call > from CleanupTempFiles, it contrives to fail to fclose a > number of files [at > a guess, floor((numAllocatedFiles-1)/2)] when > CleanupTempFiles is called > (unless I'm completely mistaken). > > Change 1: Begin search from "correct" [logical] final element of array > Change 2: Minor speed-up to CleanupTempFiles (knowing that > FreeFile iterates > from the [logical] > final element of the array) > > Apply to HEAD (bug also exists in 7.4 branch, possibly others...) > > Cheers, > Claudio > > --- > Certain disclaimers and policies apply to all email sent from > Memetrics. > For the full text of these disclaimers and policies see > href="http://www.memetrics.com/emailpolicy.html";>http://www.me > metrics.com/em > ailpolicy.html > > > --- 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 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[PATCHES] Bug in fd.c (FreeFile)
I believe FreeFile has an "off by one" type error. Apart from possibly accessing past the end of the array, when combined with the while loop call from CleanupTempFiles, it contrives to fail to fclose a number of files [at a guess, floor((numAllocatedFiles-1)/2)] when CleanupTempFiles is called (unless I'm completely mistaken). Change 1: Begin search from "correct" [logical] final element of array Change 2: Minor speed-up to CleanupTempFiles (knowing that FreeFile iterates from the [logical] final element of the array) Apply to HEAD (bug also exists in 7.4 branch, possibly others...) 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 fd.c.patch Description: Binary data ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] minor cleanup in plpgsql.sgml
Ummm - surely the original was correct? Chris Robert Treat wrote: Marcos Truchado <[EMAIL PROTECTED]> reported this on -docs yesterday. Robert Treat Index: plpgsql.sgml === RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/plpgsql.sgml,v retrieving revision 1.29 diff -c -r1.29 plpgsql.sgml *** plpgsql.sgml 12 Nov 2003 22:47:47 - 1.29 --- plpgsql.sgml 25 Nov 2003 14:12:50 - *** *** 986,994 DECLARE users_rec RECORD; - full_name varchar; BEGIN ! SELECT INTO users_rec * FROM users WHERE user_id=3; IF users_rec.homepage IS NULL THEN -- user entered no homepage, return "http://"; --- 986,993 DECLARE users_rec RECORD; BEGIN ! SELECT * FROM users WHERE user_id=3 INTO users_rec; IF users_rec.homepage IS NULL THEN -- user entered no homepage, return "http://"; ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] minor cleanup in plpgsql.sgml
Robert Treat <[EMAIL PROTECTED]> writes: > Funny. That's a good argument for doing it that way, but almost the same > argument I make for putting the INTO at the end: so as to not confuse > people with the "SELECT a,b,c INTO newtable FROM oldtable" sql syntax. > In either case ISTM the existing recommendation is flawed. Come to think of it, I think that the motivation for the existing recommendation was precisely to have a syntax that is visibly different from the SQL-level SELECT INTO, with an eye to eventually allowing the SQL construct to work too. This may not be very important though, considering that SELECT INTO is deprecated in favor of CREATE TABLE AS. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] minor cleanup in plpgsql.sgml
On Tue, 2003-11-25 at 14:24, Peter Eisentraut wrote:
> Tom Lane writes:
>
> > Robert Treat <[EMAIL PROTECTED]> writes:
> > > ! SELECT INTO users_rec * FROM users WHERE user_id=3;
> > > --- 986,993
> > > ! SELECT * FROM users WHERE user_id=3 INTO users_rec;
> >
> > Why do you want to change the example to disagree with the advice given
> > just above?
> >
> > : At present, the INTO clause can appear almost anywhere in the SELECT
> > : statement, but it is recommended to place it immediately after the
> > : SELECT key word as depicted above. Future versions of PL/pgSQL may be
> > : less forgiving about placement of the INTO clause.
>
> Well, that position is a strange choice. The standard syntax of SELECT
> INTO in embedded SQL is
>
> SELECT a, b, c INTO :x, :y, :z FROM ...
>
> This should probably be consistent.
>
Funny. That's a good argument for doing it that way, but almost the same
argument I make for putting the INTO at the end: so as to not confuse
people with the "SELECT a,b,c INTO newtable FROM oldtable" sql syntax.
In either case ISTM the existing recommendation is flawed.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] minor cleanup in plpgsql.sgml
Sorry Neil. I thought I recalled you submitting a similar patch, but
must have missed it in the archives and didn't see the change reflected
in cvs so assmeme'd that your change was in a different place.. :-(
Robert Treat
On Tue, 2003-11-25 at 14:04, Neil Conway wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > Marcos Truchado <[EMAIL PROTECTED]> reported this on -docs
> > yesterday.
>
> I submitted a patch for this typo to -patches 5 days ago.
>
> -Neil
>
>
> ---(end of broadcast)---
> TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [PATCHES] minor cleanup in plpgsql.sgml
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Well, that position is a strange choice. The standard syntax of SELECT > INTO in embedded SQL is > SELECT a, b, c INTO :x, :y, :z FROM ... > This should probably be consistent. Well, I'm not wedded to the current recommendation, but we'll never be able to clean up the current weird-hack implementation of SELECT INTO until we can freeze the syntax somehow. The above looks at least as reasonable as what we're currently recommending ... regards, tom lane ---(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: [PATCHES] minor cleanup in plpgsql.sgml
Tom Lane writes: > Robert Treat <[EMAIL PROTECTED]> writes: > > ! SELECT INTO users_rec * FROM users WHERE user_id=3; > > --- 986,993 > > ! SELECT * FROM users WHERE user_id=3 INTO users_rec; > > Why do you want to change the example to disagree with the advice given > just above? > > : At present, the INTO clause can appear almost anywhere in the SELECT > : statement, but it is recommended to place it immediately after the > : SELECT key word as depicted above. Future versions of PL/pgSQL may be > : less forgiving about placement of the INTO clause. Well, that position is a strange choice. The standard syntax of SELECT INTO in embedded SQL is SELECT a, b, c INTO :x, :y, :z FROM ... This should probably be consistent. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] Install pg_config_manual.h
Reinhard Max writes: > > I just found, that pg_config_manual.h is included by internal/c.h, > > but not being installed by default. The attached patch fixes this. > > port.h was missing as well. Updated patch attached. Fixed. The port.h goes into the "internal" subdirectory. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] minor cleanup in plpgsql.sgml
Robert Treat <[EMAIL PROTECTED]> writes: > Marcos Truchado <[EMAIL PROTECTED]> reported this on -docs > yesterday. I submitted a patch for this typo to -patches 5 days ago. -Neil ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] minor cleanup in plpgsql.sgml
On Tue, 2003-11-25 at 11:24, Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > ! SELECT INTO users_rec * FROM users WHERE user_id=3;
> > --- 986,993
> > ! SELECT * FROM users WHERE user_id=3 INTO users_rec;
>
> Why do you want to change the example to disagree with the advice given
> just above?
>
> : At present, the INTO clause can appear almost anywhere in the SELECT
> : statement, but it is recommended to place it immediately after the
> : SELECT key word as depicted above. Future versions of PL/pgSQL may be
> : less forgiving about placement of the INTO clause.
>
> regards, tom lane
guess that was an unconscious change made on my part. I tend to use that
format for writing functions since I feel it is more clear to read.
Actually if I had my druthers I'd probably remove that "advice"
entirely, but either way that change can be disregarded, but removal of
the "full_name varchar" line should still be done.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [PATCHES] minor cleanup in plpgsql.sgml
Robert Treat <[EMAIL PROTECTED]> writes: > ! SELECT INTO users_rec * FROM users WHERE user_id=3; > --- 986,993 > ! SELECT * FROM users WHERE user_id=3 INTO users_rec; Why do you want to change the example to disagree with the advice given just above? : At present, the INTO clause can appear almost anywhere in the SELECT : statement, but it is recommended to place it immediately after the : SELECT key word as depicted above. Future versions of PL/pgSQL may be : less forgiving about placement of the INTO clause. regards, tom lane ---(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
[PATCHES] minor cleanup in plpgsql.sgml
Marcos Truchado <[EMAIL PROTECTED]> reported this on -docs yesterday.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQLIndex: plpgsql.sgml
===
RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/plpgsql.sgml,v
retrieving revision 1.29
diff -c -r1.29 plpgsql.sgml
*** plpgsql.sgml 12 Nov 2003 22:47:47 - 1.29
--- plpgsql.sgml 25 Nov 2003 14:12:50 -
***
*** 986,994
DECLARE
users_rec RECORD;
- full_name varchar;
BEGIN
! SELECT INTO users_rec * FROM users WHERE user_id=3;
IF users_rec.homepage IS NULL THEN
-- user entered no homepage, return "http://";
--- 986,993
DECLARE
users_rec RECORD;
BEGIN
! SELECT * FROM users WHERE user_id=3 INTO users_rec;
IF users_rec.homepage IS NULL THEN
-- user entered no homepage, return "http://";
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] (Modified) Patch request for PostgreSQL 7.4 for HP-UX
ViSolve Open Source Team writes: > 1. s_lock.h: modified with inline tas code for the HP-C compiler What is this line all about? +#if defined(__HP_aCC) || defined(__HP_cc) There are no other compilers supported, so this seems redundant. > 2. genbki.sh: a one-line change that fixes a string concatenation problem with the > HP-C compiler (specific to included .c files). You're doing this: -TMPFILE="$TMPDIR/genbkitmp$$.c" +TMPFILE="$TMPDIR/genbkitmp$$.h" I'm afraid this will not fly, because calling the preprocessor is only portable on .c files. Generally, it's also unwise to rely in this kind of subtle side effect. We need a general solution. -- Peter Eisentraut [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
