[HACKERS] createlang patch
The man page for createlang refers to the --echo option, but in fact
that option does not exist.
This patch implements it and also expands the man page for a couple of
options that were not documented.
diff -ur postgresql-7.1RC3/doc/src/sgml/ref/createlang.sgml
postgresql-7.1cRC3/doc/src/sgml/ref/createlang.sgml
--- postgresql-7.1RC3/doc/src/sgml/ref/createlang.sgml Sun Jan 7 02:03:28 2001
+++ postgresql-7.1cRC3/doc/src/sgml/ref/createlang.sgml Sat Apr 7 08:56:26 2001
@@ -62,11 +62,39 @@
+ --pglib directory
+
+
+ Specifies the directory in which the language interpreter is
+to be found.
+
+
+
+
+
-l, --list
Shows a list of already installed languages in the target database
(which must be specified).
+
+
+
+
+
+ --echo
+
+
+Displays SQL commands as they are executed.
+
+
+
+
+
+ -?, --help
+
+
+Shows a brief help message.
diff -ur postgresql-7.1RC3/src/bin/scripts/createlang.sh
postgresql-7.1cRC3/src/bin/scripts/createlang.sh
--- postgresql-7.1RC3/src/bin/scripts/createlang.sh Fri Feb 23 18:12:18 2001
+++ postgresql-7.1cRC3/src/bin/scripts/createlang.shSat Apr 7 07:59:18 2001
@@ -98,6 +98,9 @@
PGLIB=`echo "$1" | sed 's/^--pglib=//'`
;;
+ --echo)
+ listcmd=TRUE
+ ;;
-*)
echo "$CMDNAME: invalid option: $1" 1>&2
echo "Try '$CMDNAME --help' for more information." 1>&2
@@ -155,7 +158,12 @@
# List option
# --
if [ "$list" ]; then
-${PATHNAME}psql $PSQLOPT -d "$dbname" -P 'title=Procedural languages' -c
"SELECT lanname as \"Name\", lanpltrusted as \"Trusted?\", lancompiler as \"Compiler\"
FROM pg_language WHERE lanispl = 't'"
+ sqlcmd="SELECT lanname as \"Name\", lanpltrusted as \"Trusted?\", lancompiler
+as \"Compiler\" FROM pg_language WHERE lanispl = 't'"
+ if [ -n "$listcmd" ]
+ then
+ echo $sqlcmd
+ fi
+${PATHNAME}psql $PSQLOPT -d "$dbname" -P 'title=Procedural languages' -c
+"$sqlcmd"
exit $?
fi
@@ -237,7 +245,12 @@
# --
# Make sure the language isn't already installed
# --
-res=`$PSQL "SELECT oid FROM pg_language WHERE lanname = '$langname'"`
+sqlcmd="SELECT oid FROM pg_language WHERE lanname = '$langname'"
+if [ -n "$listcmd" ]
+then
+ echo $sqlcmd
+fi
+res=`$PSQL "$sqlcmd"`
if [ $? -ne 0 ]; then
echo "$CMDNAME: external error" 1>&2
exit 1
@@ -251,7 +264,12 @@
# --
# Check that there is no function named as the call handler
# --
-res=`$PSQL "SELECT oid FROM pg_proc WHERE proname = '$handler'"`
+sqlcmd="SELECT oid FROM pg_proc WHERE proname = '$handler'"
+if [ -n "$listcmd" ]
+then
+ echo $sqlcmd
+fi
+res=`$PSQL "$sqlcmd"`
if [ ! -z "$res" ]; then
echo "$CMDNAME: A function named '$handler' already exists. Installation
aborted." 1>&2
exit 1
@@ -260,13 +278,23 @@
# --
# Create the call handler and the language
# --
-$PSQL "CREATE FUNCTION $handler () RETURNS OPAQUE AS '$PGLIB/${object}$DLSUFFIX'
LANGUAGE 'C'"
+sqlcmd="CREATE FUNCTION $handler () RETURNS OPAQUE AS '$PGLIB/${object}$DLSUFFIX'
+LANGUAGE 'C'"
+if [ -n "$listcmd" ]
+then
+ echo $sqlcmd
+fi
+$PSQL "$sqlcmd"
if [ $? -ne 0 ]; then
echo "$CMDNAME: language installation failed" 1>&2
exit 1
fi
-$PSQL "CREATE ${trusted}PROCEDURAL LANGUAGE '$langname' HANDLER $handler LANCOMPILER
'$lancomp'"
+sqlcmd="CREATE ${trusted}PROCEDURAL LANGUAGE '$langname' HANDLER $handler LANCOMPILER
+'$lancomp'"
+if [ -n "$listcmd" ]
+then
+ echo $sqlcmd
+fi
+$PSQL "$sqlcmd"
if [ $? -ne 0 ]; then
echo "$CMDNAME: language installation failed" 1>&2
exit 1
--
Oliver Elphick[EMAIL PROTECTED]
Isle of Wight http://www.lfix.co.uk/oliver
PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C
"I sought the Lord, and he answered me; he delivered me
from all my fears." Psalm 34:4
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: RC3 ... and rpms...
Franck Martin wrote: > I have no idea if what I say is true about the PG distribution by PG people, but > I have noticed than in the rpms of other distros the postgresql-devel rpms do not > include all the .h files necessary to build PG extensions. For instance the > rtree.h and itup.h and gist.h headers are missing. Could you please ensure that > all the headers are taken into account when you write your spec file. The RPMs now (as of 7.1beta4) use the 'make install-all-headers' incantation to generate the development headers. If this doesn't get the headers you need, then install-all-headers needsto be modified to really install ALL headers. With my latest RC3 RPM's (which I am preparing to upload to the PostgreSQL ftp server sometime this morning, once I get some other reorganization done and some contrib stuff built), I get the following results: [root@utility i386]# rpm -ql postgresql-devel|grep gist /usr/include/pgsql/access/gist.h /usr/include/pgsql/access/gistscan.h /usr/include/pgsql/access/giststrat.h [root@utility i386]# rpm -ql postgresql-devel|grep rtree /usr/include/pgsql/access/rtree.h [root@utility i386]# rpm -ql postgresql-devel|grep itup /usr/include/pgsql/access/itup.h [root@utility i386]# -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(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] Re: RC3 ...
Thomas Lockhart wrote: > > > > OTOH, if Marc was only thinking of removing the pre-built docs from the > > > tarball, I don't object to that. I'm not sure why those weren't > > > distributed as separate tarballs from the get-go. I just say that the > > > doc sources are part of the source distribution... > > >From the get-go, the docs were not, uh, useful docs. They have grown > quite a bit from 1996 (with sources and formatting, probably by orders > of magnitude). Today's docs make even the docs of version 6.1.1 look pretty puny. I'm looking at the package reorganization for the RPM's this morning -- we'll see what I find in a few hours. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Re: RC3 ...
The Hermit Hacker wrote: > Okay, unless someone can come up with a really good argument *for* why > docs has to be included as part of the main tar file, I'm going to change > the distributin generating script so that it generates a .src.tar.gz file > seperate from the .doc.tar.gz file, which will make .src.tar.gz ~6Meg > instead of the 8meg we are currently forcing ppl to download ... > Peter E, is there anything part of the configure/make procedure that > *requires* pgsql/doc to be there else it will break? If so, can you > possibly put it as a test "if docs exists, deal with it, else ignore"? We're going to do this at this point in the release cycle? IOW, is there going to be an RC4 with this new packaging, or is the first-off tarball with new packaging going to be the *final* 7.1 release *raised eyebrow*? I am certainly NOT opposed to doing this -- just questioning the timing. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Re: RC3 ...
On Sat, 7 Apr 2001, Lamar Owen wrote: > The Hermit Hacker wrote: > > Okay, unless someone can come up with a really good argument *for* why > > docs has to be included as part of the main tar file, I'm going to change > > the distributin generating script so that it generates a .src.tar.gz file > > seperate from the .doc.tar.gz file, which will make .src.tar.gz ~6Meg > > instead of the 8meg we are currently forcing ppl to download ... > > > Peter E, is there anything part of the configure/make procedure that > > *requires* pgsql/doc to be there else it will break? If so, can you > > possibly put it as a test "if docs exists, deal with it, else ignore"? > > We're going to do this at this point in the release cycle? IOW, is > there going to be an RC4 with this new packaging, or is the first-off > tarball with new packaging going to be the *final* 7.1 release *raised > eyebrow*? there will be an RC4, I'm just waiting to hear back from Peter E as to whether there is anything in the build process we even risk breaking ... we've been doing the whole split thing for the past release or two as it is (the FreeBSD ports collection using the individual packages instead of the great big one) so from a packaging perspective, its well tested ... ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: RC3 ...
The Hermit Hacker wrote: > there will be an RC4, I'm just waiting to hear back from Peter E as to Good. > whether there is anything in the build process we even risk breaking ... > we've been doing the whole split thing for the past release or two as it > is (the FreeBSD ports collection using the individual packages instead of > the great big one) so from a packaging perspective, its well tested ... Just not well-tested for the RPM build environment :-). -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Re: RC3 ... and rpms...
Karl DeBisschop wrote: > In my experience so far, it is also noticably slower than gzip. It does > work, and it is available. I have not yet been convinced that the space > savings is worth the time lost. But ISTM this is a minor point. The official tarball is gzipped -- the RPM will use that until bzipped tarballs are official. > Actually, since you can suppress installation of the docs with --nodocs, > I would very much prefer to keep the html and text docs in the main RPM. > Otherwise I have two directories in /usr/doc for one software suite. The html docs at the very least will remain in the main package. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(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] Re: RC3 ...
On Sat, 7 Apr 2001, Lamar Owen wrote: > The Hermit Hacker wrote: > > there will be an RC4, I'm just waiting to hear back from Peter E as to > > Good. > > > whether there is anything in the build process we even risk breaking ... > > we've been doing the whole split thing for the past release or two as it > > is (the FreeBSD ports collection using the individual packages instead of > > the great big one) so from a packaging perspective, its well tested ... > > Just not well-tested for the RPM build environment :-). Ya, but you could concievably test that now, without us doign an RC4 .. the files are all there :) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Fw: [HACKERS] QNX : POSSIBLE BUG IN CONFIGURE ?
I searched for the error and I have found : when I execute psql template0 the SIGSEGV is generated when postinit calls RelationPhaseInitializePhase2 in heap_openr with RelationName = pg_am at the return r I have the error. when I execute psql template1 the SIGSEGV is generated when postinit calls RelationPhaseInitializePhase2 in heap_openr with RelationName = pg_class at the return r I have the error. I can't understand whats happen. Could someone help me ? Thanks Maurizio Cauci . - Original Message - From: "Maurizio" <[EMAIL PROTECTED]> To: "Peter Eisentraut" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, April 03, 2001 6:31 PM Subject: Re: [HACKERS] QNX : POSSIBLE BUG IN CONFIGURE ? > OK, > I compiled postgresql RC2. I have not error nor warnings so I hope it's all > right. > I also changed something in os.h --> port/qnx4.h > and in s_lock.c > > I will post the changes until the end of the week. > > I executed initdb and all works fine. > I executed postmaster and the proces run OK. > > When I run psql template0 I have an error. I am not expert walking throu > postgresql sources. > could You tell me if there some change from beta 6 to RC1 or RC2 that can > give this problem in QNX so I can try to check all? > > Attached is the server.log file with the SIGSEGV. > > Thanks > > - Original Message - > From: "Peter Eisentraut" <[EMAIL PROTECTED]> > To: "Maurizio" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Monday, April 02, 2001 6:38 PM > Subject: Re: [HACKERS] QNX : POSSIBLE BUG IN CONFIGURE ? > > > > Maurizio writes: > > > > > the problem is : > > > > > > when I execute configure it recognize the executable suffix as .map > > > and this is not right. And the test program fails. > > > > This is a known (to me) bug in Autoconf. Maybe there's a way to prevent > > the .map files to be generated? Fixing this isn't too hard, but I don't > > feel urgent about it when there are more problems with the QNX port still > > down the line. > > > > -- > > Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ > > > > > > ---(end of broadcast)--- > > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] > > > ---(end of broadcast)--- > TIP 4: Don't 'kill -9' the postmaster > ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Re: RC3 ...
The Hermit Hacker wrote: > On Sat, 7 Apr 2001, Lamar Owen wrote: > > Just not well-tested for the RPM build environment :-). > Ya, but you could concievably test that now, without us doign an RC4 .. > the files are all there :) So the structure isn't going to change -- just there's not going to be a 'whole thing' tarball anymore? I am now confyoozzled :-) If there's still going to be a 'whole thing' tarball, I don't need to change much. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] createlang patch
I will save this for 7.2. Thanks.
> The man page for createlang refers to the --echo option, but in fact
> that option does not exist.
>
> This patch implements it and also expands the man page for a couple of
> options that were not documented.
>
> diff -ur postgresql-7.1RC3/doc/src/sgml/ref/createlang.sgml
>postgresql-7.1cRC3/doc/src/sgml/ref/createlang.sgml
> --- postgresql-7.1RC3/doc/src/sgml/ref/createlang.sgmlSun Jan 7 02:03:28
>2001
> +++ postgresql-7.1cRC3/doc/src/sgml/ref/createlang.sgml Sat Apr 7 08:56:26
>2001
> @@ -62,11 +62,39 @@
>
>
>
> + --pglib directory
> +
> +
> + Specifies the directory in which the language interpreter is
> +to be found.
> +
> +
> +
> +
> +
>-l, --list
>
>
> Shows a list of already installed languages in the target database
> (which must be specified).
> +
> +
> +
> +
> +
> + --echo
> +
> +
> +Displays SQL commands as they are executed.
> +
> +
> +
> +
> +
> + -?, --help
> +
> +
> +Shows a brief help message.
>
>
>
> diff -ur postgresql-7.1RC3/src/bin/scripts/createlang.sh
>postgresql-7.1cRC3/src/bin/scripts/createlang.sh
> --- postgresql-7.1RC3/src/bin/scripts/createlang.sh Fri Feb 23 18:12:18 2001
> +++ postgresql-7.1cRC3/src/bin/scripts/createlang.sh Sat Apr 7 07:59:18 2001
> @@ -98,6 +98,9 @@
> PGLIB=`echo "$1" | sed 's/^--pglib=//'`
> ;;
>
> + --echo)
> + listcmd=TRUE
> + ;;
> -*)
> echo "$CMDNAME: invalid option: $1" 1>&2
> echo "Try '$CMDNAME --help' for more information." 1>&2
> @@ -155,7 +158,12 @@
> # List option
> # --
> if [ "$list" ]; then
> -${PATHNAME}psql $PSQLOPT -d "$dbname" -P 'title=Procedural languages' -c
>"SELECT lanname as \"Name\", lanpltrusted as \"Trusted?\", lancompiler as
>\"Compiler\" FROM pg_language WHERE lanispl = 't'"
> + sqlcmd="SELECT lanname as \"Name\", lanpltrusted as \"Trusted?\", lancompiler
>as \"Compiler\" FROM pg_language WHERE lanispl = 't'"
> + if [ -n "$listcmd" ]
> + then
> + echo $sqlcmd
> + fi
> +${PATHNAME}psql $PSQLOPT -d "$dbname" -P 'title=Procedural languages' -c
>"$sqlcmd"
> exit $?
> fi
>
> @@ -237,7 +245,12 @@
> # --
> # Make sure the language isn't already installed
> # --
> -res=`$PSQL "SELECT oid FROM pg_language WHERE lanname = '$langname'"`
> +sqlcmd="SELECT oid FROM pg_language WHERE lanname = '$langname'"
> +if [ -n "$listcmd" ]
> +then
> + echo $sqlcmd
> +fi
> +res=`$PSQL "$sqlcmd"`
> if [ $? -ne 0 ]; then
> echo "$CMDNAME: external error" 1>&2
> exit 1
> @@ -251,7 +264,12 @@
> # --
> # Check that there is no function named as the call handler
> # --
> -res=`$PSQL "SELECT oid FROM pg_proc WHERE proname = '$handler'"`
> +sqlcmd="SELECT oid FROM pg_proc WHERE proname = '$handler'"
> +if [ -n "$listcmd" ]
> +then
> + echo $sqlcmd
> +fi
> +res=`$PSQL "$sqlcmd"`
> if [ ! -z "$res" ]; then
> echo "$CMDNAME: A function named '$handler' already exists. Installation
>aborted." 1>&2
> exit 1
> @@ -260,13 +278,23 @@
> # --
> # Create the call handler and the language
> # --
> -$PSQL "CREATE FUNCTION $handler () RETURNS OPAQUE AS '$PGLIB/${object}$DLSUFFIX'
>LANGUAGE 'C'"
> +sqlcmd="CREATE FUNCTION $handler () RETURNS OPAQUE AS '$PGLIB/${object}$DLSUFFIX'
>LANGUAGE 'C'"
> +if [ -n "$listcmd" ]
> +then
> + echo $sqlcmd
> +fi
> +$PSQL "$sqlcmd"
> if [ $? -ne 0 ]; then
> echo "$CMDNAME: language installation failed" 1>&2
> exit 1
> fi
>
> -$PSQL "CREATE ${trusted}PROCEDURAL LANGUAGE '$langname' HANDLER $handler
>LANCOMPILER '$lancomp'"
> +sqlcmd="CREATE ${trusted}PROCEDURAL LANGUAGE '$langname' HANDLER $handler
>LANCOMPILER '$lancomp'"
> +if [ -n "$listcmd" ]
> +then
> + echo $sqlcmd
> +fi
> +$PSQL "$sqlcmd"
> if [ $? -ne 0 ]; then
> echo "$CMDNAME: language installation failed" 1>&2
> exit 1
>
> --
> Oliver Elphick[EMAIL PROTECTED]
> Isle of Wight http://www.lfix.co.uk/oliver
> PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47
> GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C
>
> "I sought the Lord, and he answered me; he delivered me
> from all my fears." Psalm 34:4
>
>
> ---(end of broadcast)---
> TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
>
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 8
[HACKERS] Re: RC3 ...
Thomas Lockhart writes: > > > The docs are ready for shipment. > > Even better ... > > Okay, let's let this sit as RC3 for the next week... > > I'll go ahead and start generating hardcopy, though I understand that it > is no longer allowed into the shipping tarball :( I'm not speaking about "allowed", I'm merely talking about the state of affairs since 7.0. If people think that the postscript format should be in the main tarball, then why not, but IIRC this question was raised last time around and the decision went the other way. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] Re: RC3 ...
The Hermit Hacker writes: > At 2Meg, is there a reason why we include any of the docs as part of the > standard tar ball? It shouldn't be required to compile, so should be able > to be left out of the main tar ball and downloaded seperately as required > .. thereby shrinking the distribution to <6Meg from its current 8 ... For that purpose you introduced the split distribution. If there is any good reason for it, it's this. Currently, the .docs sub-tarball contains the entire doc/ subtree, the consequence of which is that this tarball is required for a functioning installation. If we were to change this split so that doc/src/ is a separate sub-tarball, then that one could be purely optional and you could tell people that they don't need it unless they want to write documentation. However, removing any part of the documentation, built or source, from the full tarball seems like a really bad idea. It breaks the fundamental principle behind a "full tarball". The resulting confusion would be enormous. Especially now that we seems to start getting some outside documentation contributors. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Re: RC3 ...
Bruce Momjian writes: > Can we drop TODO.detail from the tarball too? No need to include that, > I think. The web site has nice links to it now. Uncompressed it is > 1.314 megs. You see where this discussion goes? Do we want to go through each file and argue whether it needs to be distributed? If you're in that kind of mood then you should use a binary package. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Re: RC3 ...
Tom Lane writes: > OTOH, if Marc was only thinking of removing the pre-built docs from the > tarball, I don't object to that. I'm not sure why those weren't > distributed as separate tarballs from the get-go. I just say that the > doc sources are part of the source distribution... Why would you want to remove the pre-built docs from the tarball and ship the sources? -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Re: RC3 ...
Lamar Owen writes: > We're going to do this at this point in the release cycle? IOW, is > there going to be an RC4 with this new packaging, or is the first-off > tarball with new packaging going to be the *final* 7.1 release *raised > eyebrow*? > > I am certainly NOT opposed to doing this -- just questioning the timing. I'm also questioning the timing and I am undoubtedly opposed to this. We're talking about butchering up the released distribution less than a week before publication. We had a year to discuss this and various questions about how to handle documentation building, distributions, and installation were raised during that time. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: RC3 ...
The Hermit Hacker writes: > Okay, unless someone can come up with a really good argument *for* why > docs has to be included as part of the main tar file, Because people want to read the documentation. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Re: RC3 ...
Bruce Momjian writes: > A major issue is that we don't regenerate docs for 7.1.1 or later, so Sure we do. > the 7.1 docs carry for all the 7.1.X releases. That would seem to argue > for a separate tarball for docs so people don't redownload the docs > again for 7.1.1. > > -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(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] Re: RC3 ...
The Hermit Hacker writes: > On Sat, 7 Apr 2001, Peter Eisentraut wrote: > > > The Hermit Hacker writes: > > > > > Okay, unless someone can come up with a really good argument *for* why > > > docs has to be included as part of the main tar file, > > > > Because people want to read the documentation. > > get postgresql.src.tar.gz > get postgresql.docs.tar.gz > > instead of just > > get postgresql.tar.gz But we already have a set of split distributions. If you want to split it in a different way, why not, but abolishing the full distribution is going to seriously alienate use from the conventions used in open source land. > I'm curious as to how many ppl would actually download those docs ... This is the wrong question to ask. The real question to me is: If we do this, how many people won't download the documentation, don't read it, don't find it, spread the word that PostgreSQL is poorly documented, don't use it correctly, spread the word that PostgreSQL isn't easy to use, and take our time with avoidable mailing list traffic? Also, how many people will consequently not even get a chance to contribute to the documentation? People won't do two downloads for marginal benefit. But let me ask you this: If we split out the documentation, why stop there? Why not leave out pgtclsh, how many people need that? Or what about the JDBC driver sources? People can download the pre-compiled jar file. These are in fact valid concerns, and they are adressed by the split tarballs that we offer. But there *must* be a full source tarball. I cannot count on two hands the occasion where I had a source package where people left out "non-essential" source files. They lost me as a contributor. I'm not going to set up a CVS pull to fix a sentence. > I > know that I'd never do so, as I'm never on the same machine that the > server is running from, so just hit the web site ... I think you would be glad if more people read them locally and less people hit the web. ;-) > so, for those that do, we are giving them one extra step, and for those > that don't, saving them time and bandwidth ... People that want to save time and bandwidth use binary packages or the split tarballs that we already have. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(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] Re: RC3 ...
The Hermit Hacker writes: > those that don't want it, it sames them 2meg of download time ... Another way to save at least 1 MB of download time would be bzip2'ed tarballs. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Re: Call for platforms
Giles Lean <[EMAIL PROTECTED]> writes: > It is still necessary to add -ltermcap after -ledit in > src/Makefile.global to have functional history editing in psql. This is a weakness in the configure script: it goes through a loop where it tries to link a program that calls readline() with, in order, "-lreadline", "-lreadline -ltermcap", "-lreadline -lncurses", "-lreadline -lcurses", "-ledit", "-ledit -ltermcap", "-ledit -lncurses" and "-ledit -lcurses". The first link that succeeds wil determine which libraries are used. However, on some platforms with dynamic libraries, the link will succeed as soon as readline() is present -- but the shared library that contains it doesn't contain a complete specification of all other libraries it needs at run-time (the executable is expected to hold this information), and the program fails at run-time even though it linked without any error message. I don't know how the situation could best be improved, though... -tih -- The basic difference is this: hackers build things, crackers break them. ---(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] Re: RC3 ...
> Bruce Momjian writes: > > > A major issue is that we don't regenerate docs for 7.1.1 or later, so > > Sure we do. > > > the 7.1 docs carry for all the 7.1.X releases. That would seem to argue > > for a separate tarball for docs so people don't redownload the docs > > again for 7.1.1. I didn't know that. I thought we genarated postscript only major releases. Do we regenerate HTML for subreleases? -- 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 4: Don't 'kill -9' the postmaster
[HACKERS] Re: RC3 ...
On Sat, 7 Apr 2001, Peter Eisentraut wrote: > Thomas Lockhart writes: > > > > > The docs are ready for shipment. > > > Even better ... > > > Okay, let's let this sit as RC3 for the next week... > > > > I'll go ahead and start generating hardcopy, though I understand that it > > is no longer allowed into the shipping tarball :( > > I'm not speaking about "allowed", I'm merely talking about the state of > affairs since 7.0. If people think that the postscript format should be > in the main tarball, then why not, but IIRC this question was raised last > time around and the decision went the other way. Having had to d/l PG many times on many different machines, I'd be delighted if it came w/o .ps docs, and w/o the doc sources (the number of people who seem to be able to turn docbook into useful stuff seems to be << than people who can successful compile PG!). It sounds like the separate-tgz for docs and for Postscript makes perfect sense. Just make sure that it's *very* obvious where/how to get these, so that the mailing lists are deluged w/ 'where are the docs'? Just my .02, -- Joel Burton <[EMAIL PROTECTED]> Director of Information Systems, Support Center of Washington ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Re: Call for platforms
Tom Ivar Helbekkmo writes: > Giles Lean <[EMAIL PROTECTED]> writes: > > > It is still necessary to add -ltermcap after -ledit in > > src/Makefile.global to have functional history editing in psql. > > This is a weakness in the configure script: it goes through a loop > where it tries to link a program that calls readline() with, in order, > "-lreadline", "-lreadline -ltermcap", "-lreadline -lncurses", > "-lreadline -lcurses", "-ledit", "-ledit -ltermcap", "-ledit > -lncurses" and "-ledit -lcurses". The first link that succeeds wil > determine which libraries are used. However, on some platforms with > dynamic libraries, the link will succeed as soon as readline() is > present -- but the shared library that contains it doesn't contain a > complete specification of all other libraries it needs at run-time > (the executable is expected to hold this information), and the program > fails at run-time even though it linked without any error message. On such a platform it would hardly be possible to detect anything with any reliably. A linker that links a program "succesfully" while the program really needs more libraries to be runnable isn't very useful. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: Call for platforms
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> On such a platform it would hardly be possible to detect anything with any
> reliably. A linker that links a program "succesfully" while the program
> really needs more libraries to be runnable isn't very useful.
You're right, of course -- it's a bug in the linkage loader on the
platform in question. NetBSD/vax has it:
$ uname -a
NetBSD varg.i.eunet.no 1.5T NetBSD 1.5T (VARG) #4: Thu Apr 5 23:38:04 CEST 2001
[EMAIL PROTECTED]:/usr/src/sys/arch/vax/compile/VARG vax
$ cat > foo.c
int main (int argc, char **argv) { readline(); }
$ cc -o foo foo.c
/tmp/ccFTO4Mu.o: Undefined symbol `_readline'referenced from text segment
collect2: ld returned 1 exit status
$ cc -o foo foo.c -ledit
$ echo $?
0
$ ./foo
/usr/libexec/ld.so: Undefined symbol "_tputs"in foo:/usr/lib/libedit.so.2.5
$ echo $?
1
$ ldd foo
foo:
-ledit.2 => /usr/lib/libedit.so.2.5 (0x181b000)
-lc.12 => /usr/lib/libc.so.12.74 (0x182d000)
$
-tih
--
The basic difference is this: hackers build things, crackers break them.
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] Message of move
Hi.
A few weeks (months?) ago I made a patch to the postgres
backend to get back the number of realized moves after
a MOVE command. So if I issue a "MOVE 100 IN cusrorname",
but there was only 66 rows left, I get back not only "MOVE",
but "MOVE 66". If the 100 steps could be realized, then
"MOVE 100" would come back.
I send this info to you, because I would like to ask you if
it could be OK to include in future versions. I think you
are in a beta testing phase now, so it is trivially not the
time to include it now...
The solution is 2 code lines into command.c, and then the
message of move cames with the number into for example psql.
1 other word into the jdbc driver, and this number is
available at update_count.
I made the patch to the latest (one day old) CVS version.
Here are the patches. Please look at them, and if you think
it's a good idea, then please let me know where and how should
I post them, and approximately when will you finish with the
beta testing, so it can be really considered seriously.
I included them also as an attachment, because my silly pine
insists to break the lines...
--- ./src/backend/commands/command.c.orig Fri Mar 23 05:49:52 2001
+++ ./src/backend/commands/command.cSat Apr 7 10:24:27 2001
@@ -174,6 +174,12 @@
if (!portal->atEnd)
{
ExecutorRun(queryDesc, estate, EXEC_FOR, (long) count);
+
+ /* I use CMD_UPDATE, because no CMD_MOVE or the like
+ exists, and I would like to provide the same
+ kind of info as CMD_UPDATE */
+ UpdateCommandInfo(CMD_UPDATE, 0, estate->es_processed);
+
if (estate->es_processed > 0)
portal->atStart = false;/* OK to back
up now */
if (count <= 0 || (int) estate->es_processed < count)
@@ -185,6 +191,12 @@
if (!portal->atStart)
{
ExecutorRun(queryDesc, estate, EXEC_BACK, (long) count);
+
+ /* I use CMD_UPDATE, because no CMD_MOVE or the like
+ exists, and I would like to provide the same
+ kind of info as CMD_UPDATE */
+ UpdateCommandInfo(CMD_UPDATE, 0, -1*estate->es_processed);
+
if (estate->es_processed > 0)
portal->atEnd = false; /* OK to go forward now */
if (count <= 0 || (int) estate->es_processed < count)
Here is the patch for the jdbc driver. >! I couldn't test it
with the current version, because it needs ant, and I didn't
have time and money today to download it... !< However, it
is a trivial change, and if Peter T. Mount reads it, I ask
him to check if he likes it... Thanks for any kind of answer.
--- ./src/interfaces/jdbc/org/postgresql/Connection.java.orig Wed Jan 31 09:26:01
2001
+++ ./src/interfaces/jdbc/org/postgresql/Connection.javaSat Apr 7 16:42:04
+2001
@@ -490,7 +490,7 @@
recv_status =
pg_stream.ReceiveString(receive_sbuf,8192,getEncoding());
// Now handle the update count correctly.
- if(recv_status.startsWith("INSERT") ||
recv_status.startsWith("UPDATE") || recv_status.startsWith("DELETE")) {
+ if(recv_status.startsWith("INSERT") ||
+recv_status.startsWith("UPDATE") || recv_status.startsWith("DELETE") ||
+recv_status.startsWith("MOVE")) {
try {
update_count =
Integer.parseInt(recv_status.substring(1+recv_status.lastIndexOf(' ')));
} catch(NumberFormatException nfe) {
---
(This last looks a bit complex, but the change is really a new
"|| recv_status.startsWith("MOVE")" only...)
Thank you for having read this,
Baldvin
p.s.: I read a page on your homepage, called "unapplied patches".
I would like to know if it means "still unapplied patches", or
it means "bad, and not accepted ideas".
--- ./src/backend/commands/command.c.orig Fri Mar 23 05:49:52 2001
+++ ./src/backend/commands/command.cSat Apr 7 10:24:27 2001
@@ -174,6 +174,12 @@
if (!portal->atEnd)
{
ExecutorRun(queryDesc, estate, EXEC_FOR, (long) count);
+
+ /* I use CMD_UPDATE, because no CMD_MOVE or the like
+ exists, and I would like to provide the same
+ kind of info as CMD_UPDATE */
+ UpdateCommandInfo(CMD_UPDATE, 0, estate->es_processed);
+
if (estate->es_processed > 0)
portal->atStart = false;/* OK to back
up now */
if (cou
[HACKERS] The makefile of pgaccess (CVS)
Hi!
I had very funny problems with "make install" of the
CVS version. The clue was a bit strange behavior of bash
(/bin/sh is only a link in my debian).
The whole thing is about wildcard expansion: there's an
option called nocaseglob. I never heard of it before,
but this was the cause for the Error 1 while make install.
I don't know, what is the default of this option in
bash, but in my computer shows different behaviour with
interactive shells and non interactives.
I had to make a patch, qiute trivial, in src/bin/pgaccess/Makefile.
I changed the language-installer line so it checks whether it
doesn't really try to copy the CVS subdirectory as a language...
If anyone is interested in it, here's the patch:
--- ./src/bin/pgaccess/Makefile.origSun Feb 18 19:34:01 2001
+++ ./src/bin/pgaccess/Makefile Sat Apr 7 16:05:01 2001
@@ -30,7 +30,7 @@
$(INSTALL_SCRIPT) $(srcdir)/main.tcl $(DESTDIR)$(pgaccessdir)
for i in $(srcdir)/lib/*.tcl; do $(INSTALL_DATA) $$i
$(DESTDIR)$(pgaccessdir)/lib || exit 1; done
for i in $(srcdir)/lib/help/*.hlp; do $(INSTALL_DATA) $$i
$(DESTDIR)$(pgaccessdir)/lib/help || exit 1; done
- for i in $(srcdir)/lib/languages/[a-z]*; do $(INSTALL_DATA) $$i
$(DESTDIR)$(pgaccessdir)/lib/languages || exit 1; done
+ for i in $(srcdir)/lib/languages/[a-z]*; do [ -f "$$i" ] && { $(INSTALL_DATA)
+$$i $(DESTDIR)$(pgaccessdir)/lib/languages || exit 1; }; done
for i in $(srcdir)/images/*.gif; do $(INSTALL_DATA) $$i
$(DESTDIR)$(pgaccessdir)/images || exit 1; done
installdirs:
Bye,
Baldvin
--- ./src/bin/pgaccess/Makefile.origSun Feb 18 19:34:01 2001
+++ ./src/bin/pgaccess/Makefile Sat Apr 7 16:05:01 2001
@@ -30,7 +30,7 @@
$(INSTALL_SCRIPT) $(srcdir)/main.tcl $(DESTDIR)$(pgaccessdir)
for i in $(srcdir)/lib/*.tcl; do $(INSTALL_DATA) $$i
$(DESTDIR)$(pgaccessdir)/lib || exit 1; done
for i in $(srcdir)/lib/help/*.hlp; do $(INSTALL_DATA) $$i
$(DESTDIR)$(pgaccessdir)/lib/help || exit 1; done
- for i in $(srcdir)/lib/languages/[a-z]*; do $(INSTALL_DATA) $$i
$(DESTDIR)$(pgaccessdir)/lib/languages || exit 1; done
+ for i in $(srcdir)/lib/languages/[a-z]*; do [ -f "$$i" ] && { $(INSTALL_DATA)
+$$i $(DESTDIR)$(pgaccessdir)/lib/languages || exit 1; }; done
for i in $(srcdir)/images/*.gif; do $(INSTALL_DATA) $$i
$(DESTDIR)$(pgaccessdir)/images || exit 1; done
installdirs:
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] A more useful way to split the distribution
Since people suddenly seem to be suffering from bandwidth concerns I have devised a new distribution split to address this issue. I propose the following four sub-tarballs: * postgresql-XXX.base.tar.gz3.3 MB Everything not in one of the ones below. * postgresql-XXX.opt.tar.gz 1.7 MB Everything not needed unless you use one of the following configure options: --with-CXX --with-tcl --with-perl --with-python --with-java --enable-multibyte --enable-odbc, plus some other not-really-needed things. The exact directory list is src/bin/: pgaccess pgtclsh pg_encoding src/interfaces: odbc libpq++ libpgtcl perl5 python jdbc src/pl/: plperl tcl src/backend/utils/mb contrib/retep src/tools build.xml * postgresql-XXX.docs.tar.gz1.9 MB doc/postgres.tar.gz doc/src doc/TODO.detail doc/internals.ps (Note man pages are in .base.) * postgresql-XXX.test.tar.gz1.0 MB src/test All this is proportionally about the same as right now, except that each tarball except base would now be truly optional. So someone that only wants to use, say, PHP and psql only needs to download the base package. Patch below. Yes/no/maybe? --- GNUmakefile.in Sun Apr 8 01:14:23 2001 +++ GNUmakefile2Sun Apr 8 01:19:55 2001 @@ -60,7 +60,7 @@ dist: $(distdir).tar.gz ifeq ($(split-dist), yes) -dist: $(distdir).base.tar.gz $(distdir).docs.tar.gz $(distdir).support.tar.gz $(distdir).test.tar.gz +dist: $(distdir).base.tar.gz $(distdir).docs.tar.gz $(distdir).opt.tar.gz +$(distdir).test.tar.gz endif dist: -rm -rf $(distdir) @@ -68,15 +68,22 @@ $(distdir).tar: distdir $(TAR) chf $@ $(distdir) +opt_files := $(addprefix src/bin/, pgaccess pgtclsh pg_encoding) \ + $(addprefix src/interfaces/, odbc libpq++ libpgtcl perl5 python jdbc) \ + $(addprefix src/pl/, plperl tcl) \ + src/backend/utils/mb contrib/retep src/tools build.xml + +docs_files := doc/postgres.tar.gz doc/src doc/TODO.detail doc/internals.ps + $(distdir).base.tar: distdir - $(TAR) -c $(addprefix --exclude $(distdir)/, doc src/test src/interfaces src/bin) \ + $(TAR) -c $(addprefix --exclude $(distdir)/, $(docs_files) $(opt_files) +src/test) \ -f $@ $(distdir) $(distdir).docs.tar: distdir - $(TAR) cf $@ $(distdir)/doc + $(TAR) cf $@ $(addprefix $(distdir)/, $(docs_files)) -$(distdir).support.tar: distdir - $(TAR) cf $@ $(distdir)/src/interfaces $(distdir)/src/bin +$(distdir).opt.tar: distdir + $(TAR) cf $@ $(addprefix $(distdir)/, $(opt_files)) $(distdir).test.tar: distdir $(TAR) cf $@ $(distdir)/src/test ===snip -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] A more useful way to split the distribution
Oh, I definitely like this ... and get rid of the *large* file, which will
save all the mirrors a good deal of space over time ...
On Sun, 8 Apr 2001, Peter Eisentraut wrote:
> Since people suddenly seem to be suffering from bandwidth concerns I have
> devised a new distribution split to address this issue. I propose the
> following four sub-tarballs:
>
> * postgresql-XXX.base.tar.gz 3.3 MB
>
> Everything not in one of the ones below.
>
> * postgresql-XXX.opt.tar.gz 1.7 MB
>
> Everything not needed unless you use one of the following configure
> options: --with-CXX --with-tcl --with-perl --with-python --with-java
> --enable-multibyte --enable-odbc, plus some other not-really-needed
> things.
>
> The exact directory list is
> src/bin/: pgaccess pgtclsh pg_encoding
> src/interfaces: odbc libpq++ libpgtcl perl5 python jdbc
> src/pl/: plperl tcl
> src/backend/utils/mb contrib/retep src/tools build.xml
>
> * postgresql-XXX.docs.tar.gz 1.9 MB
>
> doc/postgres.tar.gz doc/src doc/TODO.detail doc/internals.ps
>
> (Note man pages are in .base.)
>
> * postgresql-XXX.test.tar.gz 1.0 MB
>
> src/test
>
> All this is proportionally about the same as right now, except that each
> tarball except base would now be truly optional. So someone that only
> wants to use, say, PHP and psql only needs to download the base package.
>
> Patch below. Yes/no/maybe?
>
> --- GNUmakefile.in Sun Apr 8 01:14:23 2001
> +++ GNUmakefile2Sun Apr 8 01:19:55 2001
> @@ -60,7 +60,7 @@
>
> dist: $(distdir).tar.gz
> ifeq ($(split-dist), yes)
> -dist: $(distdir).base.tar.gz $(distdir).docs.tar.gz $(distdir).support.tar.gz
>$(distdir).test.tar.gz
> +dist: $(distdir).base.tar.gz $(distdir).docs.tar.gz $(distdir).opt.tar.gz
>$(distdir).test.tar.gz
> endif
> dist:
> -rm -rf $(distdir)
> @@ -68,15 +68,22 @@
> $(distdir).tar: distdir
> $(TAR) chf $@ $(distdir)
>
> +opt_files := $(addprefix src/bin/, pgaccess pgtclsh pg_encoding) \
> + $(addprefix src/interfaces/, odbc libpq++ libpgtcl perl5 python jdbc) \
> + $(addprefix src/pl/, plperl tcl) \
> + src/backend/utils/mb contrib/retep src/tools build.xml
> +
> +docs_files := doc/postgres.tar.gz doc/src doc/TODO.detail doc/internals.ps
> +
> $(distdir).base.tar: distdir
> - $(TAR) -c $(addprefix --exclude $(distdir)/, doc src/test src/interfaces
>src/bin) \
> + $(TAR) -c $(addprefix --exclude $(distdir)/, $(docs_files) $(opt_files)
>src/test) \
> -f $@ $(distdir)
>
> $(distdir).docs.tar: distdir
> - $(TAR) cf $@ $(distdir)/doc
> + $(TAR) cf $@ $(addprefix $(distdir)/, $(docs_files))
>
> -$(distdir).support.tar: distdir
> - $(TAR) cf $@ $(distdir)/src/interfaces $(distdir)/src/bin
> +$(distdir).opt.tar: distdir
> + $(TAR) cf $@ $(addprefix $(distdir)/, $(opt_files))
>
> $(distdir).test.tar: distdir
> $(TAR) cf $@ $(distdir)/src/test
> ===snip
>
> --
> Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
>
>
> ---(end of broadcast)---
> TIP 6: Have you searched our list archives?
>
> http://www.postgresql.org/search.mpl
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
Re: [HACKERS] A more useful way to split the distribution
The Hermit Hacker wrote: > Oh, I definitely like this ... and get rid of the *large* file, which will > save all the mirrors a good deal of space over time ... You gonna make a set of RC3 or 4 tarballs along these lines to test? I want to try a build with this split before doing too much else -- well, actually, I just want to make sure I get it right before release, as I'd like to not have but a couple of days before an RPM release after the announcement. Sounds like a plan. I'm going to upload a set of RC3 RPM's tonight -- there are changes that I need people to comment upon. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] 7.1RC3 passes as 64 bit application on HP-UX 11.00
As the subject says, PostgreSQL 7.1RC3 passes 'make check' when built as a 64 bit application on HP-UX 11.00. Yes Vince, I've added it to your results page too: http://www.postgresql.org/~vev/regress/report.php?50 Regards, Giles ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] A more useful way to split the distribution
as soon as Peter commits the changes, I'll do up an RC4 with the new
format so that everyone can test it ...
On Sat, 7 Apr 2001, Lamar Owen wrote:
> The Hermit Hacker wrote:
> > Oh, I definitely like this ... and get rid of the *large* file, which will
> > save all the mirrors a good deal of space over time ...
>
> You gonna make a set of RC3 or 4 tarballs along these lines to test? I
> want to try a build with this split before doing too much else -- well,
> actually, I just want to make sure I get it right before release, as I'd
> like to not have but a couple of days before an RPM release after the
> announcement.
>
> Sounds like a plan.
>
> I'm going to upload a set of RC3 RPM's tonight -- there are changes that
> I need people to comment upon.
> --
> Lamar Owen
> WGCR Internet Radio
> 1 Peter 4:11
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] A more useful way to split the distribution
On Sat, 7 Apr 2001, The Hermit Hacker wrote: > > Oh, I definitely like this ... and get rid of the *large* file, which will > save all the mirrors a good deal of space over time ... > > On Sun, 8 Apr 2001, Peter Eisentraut wrote: > > > Since people suddenly seem to be suffering from bandwidth concerns I have > > devised a new distribution split to address this issue. I propose the > > following four sub-tarballs: > > > > * postgresql-XXX.base.tar.gz3.3 MB > > > > Everything not in one of the ones below. > > > > * postgresql-XXX.opt.tar.gz 1.7 MB > > > > Everything not needed unless you use one of the following configure > > options: --with-CXX --with-tcl --with-perl --with-python --with-java > > --enable-multibyte --enable-odbc, plus some other not-really-needed > > things. As long as there's still the FULL tarball with everything in it available. 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]
[HACKERS] Re: [ADMIN] pgmonitor completed
You don't need pltcl, just libtcl. > > I tried to intall pltcl, but failed when I tried to build a > pltcl.so > it seems hangging on there forever, what's wrong?? > > su-2.04# cd /work/src/pgsql702/src/pl/tcl/ > su-2.04# ls > CVS mkMakefile.tcldefs.sh.in > INSTALL modules > Makefilepltcl.c > license.terms pltcl_guide.nr > mkMakefile.tcldefs.sh test > su-2.04# gmake > Makefile:22: Makefile.tcldefs: No such file or directory > /bin/sh ./mkMakefile.tcldefs.sh > ^Cgmake: *** Deleting file `Makefile.tcldefs' > gmake: *** [Makefile.tcldefs] Interrupt > > > Jie LIANG > > St. Bernard Software > > 10350 Science Center Drive > Suite 100, San Diego, CA 92121 > Office:(858)320-4873 > > [EMAIL PROTECTED] > www.stbernard.com > www.ipinc.com > > > -- 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])
Re: [HACKERS] Re: RC3 ...
On Sat, 7 Apr 2001, Peter Eisentraut wrote: > The Hermit Hacker writes: > > > Okay, unless someone can come up with a really good argument *for* why > > docs has to be included as part of the main tar file, > > Because people want to read the documentation. get postgresql.src.tar.gz get postgresql.docs.tar.gz instead of just get postgresql.tar.gz for those that want to download the docs, same amount of time ... for those that don't want it, it sames them 2meg of download time ... I'm curious as to how many ppl would actually download those docs ... I know that I'd never do so, as I'm never on the same machine that the server is running from, so just hit the web site ... so, for those that do, we are giving them one extra step, and for those that don't, saving them time and bandwidth ... ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Re: RC3 ... and rpms...
Franck Martin wrote: > > I have no idea if what I say is true about the PG distribution by PG people, but > I have noticed than in the rpms of other distros the postgresql-devel rpms do not > include all the .h files necessary to build PG extensions. For instance the > rtree.h and itup.h and gist.h headers are missing. Could you please ensure that > all the headers are taken into account when you write your spec file. > > May be also in the tar.gz or tar.bz2 distribution (bz2 is more effective than gz > and available on all platforms) you add a developer file that list all the > required headers, so that package builders know which files to include. In my experience so far, it is also noticably slower than gzip. It does work, and it is available. I have not yet been convinced that the space savings is worth the time lost. But ISTM this is a minor point. > It seems that the rpm distributions will go as: > postgresql > postgresql-docs (user and manager docs) > postgresql-devel (header files and developper docs) Actually, since you can suppress installation of the docs with --nodocs, I would very much prefer to keep the html and text docs in the main RPM. Otherwise I have two directories in /usr/doc for one software suite. The 'hard copy' docs can go whereever they want as far as I'm concerned, since I typically have little use for paper these days. Of course, these are only my preferences, but it seems unlikely that the assertions above are universally accepted either. -- Karl DeBisschop ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Re: [ADMIN] pgmonitor completed
I tried to intall pltcl, but failed when I tried to build a pltcl.so it seems hangging on there forever, what's wrong?? su-2.04# cd /work/src/pgsql702/src/pl/tcl/ su-2.04# ls CVS mkMakefile.tcldefs.sh.in INSTALL modules Makefilepltcl.c license.terms pltcl_guide.nr mkMakefile.tcldefs.sh test su-2.04# gmake Makefile:22: Makefile.tcldefs: No such file or directory /bin/sh ./mkMakefile.tcldefs.sh ^Cgmake: *** Deleting file `Makefile.tcldefs' gmake: *** [Makefile.tcldefs] Interrupt Jie LIANG St. Bernard Software 10350 Science Center Drive Suite 100, San Diego, CA 92121 Office:(858)320-4873 [EMAIL PROTECTED] www.stbernard.com www.ipinc.com ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] RE: [BUGS] Loosing files after backend crash
> -Original Message-
> From: Mikheev, Vadim [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, April 04, 2001 3:37 AM
> To: 'Tom Lane'
> Subject: RE: [BUGS] Loosing files after backend crash
>
>
> 1. Indices could be recreated with REINDEX or pg_class could
> be queried
> with seq scan (something like where relname like
> '%seq_i___data_buffer%')...
> Konstantin?
Well, bad news. After a few more tries to crash the backend, the whole
postmaster crashed and didn't rise back.
It fails to start up reporting "Apr 4 18:53:05 wale postgres[71618]: [9]
FATAL 2: XLogWrite: write request is past end of log" to syslog.
And the last line of errlog sounds like "/usr/local/pgsql/bin/postmaster:
Startup proc 72905 exited with status 512 - abort"
I wanted to ask, if I need to re-initdb or there are some other ways to fix
the problem?
If I need to re-init, can I preserve the database in it's current state, to
continue my investigation from the point I was interrupted?
I hope I will be able to answer your questions after I heal the postmaster.
> 3. Could you help us reproduce this bug, Konstantin?
> What exactly did you do after sequence creation?
Here's the script which creates the sequence and the temp table:
-8<-
begin transaction;
drop sequence _seq_i___data_buffer;
create sequence _seq_i___data_buffer;
CREATE TEMPORARY TABLE __data_buffer (
buff_id int4 UNIQUE NOT NULL default NEXTVAL( '_seq_i___data_buffer' ),
rule_id int4 NOT NULL,
_value decimal( 18, 0) NOT NULL,
_count decimal( 18, 0) NOT NULL,
value_time timestamp NOT NULL
);
insert into __data_buffer
(buff_id , rule_id , _value , _count
, value_time )
(
... [689 UNION'd selects]
);
commit;
-8<-
After that I run my function.
Shall I send you it's code? (It's 23 Kbytes big).
> Does your function reference temp table you've mentioned?
Yes. And it also creates three more temporary tables (Let's call them A, B
and C).
Actually, temp table 'A' is populated with the values from the external
temptable ('__data_buffer').
And the 'B' temp table is populated with a query from temptable A.
Then table C is populated with a huge query, which joins many tables and
table 'B' among them.
But tables 'A' and the external one are not referenced in this huge query.
Well, this very query crashes the postmaster.
Our team is playing with this query to locate the reasons for this failure.
We will report you the results of our investigation.
If you want to have a look at the query, here it is.
'__vars_info' is what I referenced as temptable C.
'__rule_data_with_tis' is what I referenced as temptable 'B'.
All other tables are not temporary.
int1 is my self-written type. To prevent from blaming my type I can say,
that replacing it with, say, float gives the same results.
datediff() is my own function (MS SQL analog, works well alone).
-8<-
INSERT INTO __vars_info ( var_id, min_old_ti, max_old_ti, lifetime,
timeinterval )
( SELECT variable.var_id,
CASE
WHEN year = 1 THEN MIN( datediff(''year'', basetime, timebegin))
WHEN month = 1 THEN MIN( datediff(''month'', basetime, timebegin))
WHEN week = 1 THEN MIN( datediff(''week'', basetime, timebegin))
WHEN day = 1 THEN MIN( datediff(''day'', basetime, timebegin))
WHEN hour = 1 THEN MIN( datediff(''hour'', basetime, timebegin))
WHEN five_minute = 1 THEN MIN( datediff(''minute'', basetime,
timebegin) / 5)
END as min_old_ti,
CASE
WHEN year = 1 THEN MAX( datediff(''year'', basetime, timebegin))
WHEN month = 1 THEN MAX( datediff(''month'', basetime, timebegin))
WHEN week = 1 THEN MAX( datediff(''week'', basetime, timebegin))
WHEN day = 1 THEN MAX( datediff(''day'', basetime, timebegin))
WHEN hour = 1 THEN MAX( datediff(''hour'', basetime, timebegin))
WHEN five_minute = 1 THEN MAX( datediff(''minute'', basetime,
timebegin) / 5)
END as max_old_ti,
lifetime, timeinterval
FROM
variable
LEFT JOIN
( SELECT var_id, timebegin FROM var_value WHERE var_id IN
( SELECT DISTINCT var_id FROM variable WHERE vset_id IN
( SELECT DISTINCT vset_id FROM vset_to_rule WHERE rule_id IN
( SELECT DISTINCT rule_id FROM __rule_data_with_tis ) ) ) )
AS sel_var_value
ON variable.var_id = sel_var_value.var_id,
( SELECT ti_id, (year)::int1 AS year, (month)::int1 AS month,
(week)::int1 AS week, (day)::int1 AS day,
(hour)::int1 AS hour, (five_minute)::int1 AS five_minute
FROM timeinterval )
AS timeinterval
WHERE
variable.ti_id = timeinterval.ti_id AND
variable.isactive = 1 AND variable.vset_id IN
( SELECT DISTINCT vset_id FROM vset_to_rule
WHERE vset_id IN ( SELECT DISTINCT vset_id FROM variable_set where
isactive = 1 ) AND
[HACKERS] Re: Table Structure
> >Hi EveryBody: > >How can i get the structure of a table (Fields names, data types, etc) try this: \d table ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] libtcl
What I need to do to install libtcl Do I still need to createlang -d dbname pltcl?? and when?? Jie LIANG St. Bernard Software 10350 Science Center Drive Suite 100, San Diego, CA 92121 Office:(858)320-4873 [EMAIL PROTECTED] www.stbernard.com www.ipinc.com On Sat, 7 Apr 2001, Bruce Momjian wrote: > You don't need pltcl, just libtcl. > > > > > I tried to intall pltcl, but failed when I tried to build a > > pltcl.so > > it seems hangging on there forever, what's wrong?? > > > > su-2.04# cd /work/src/pgsql702/src/pl/tcl/ > > su-2.04# ls > > CVS mkMakefile.tcldefs.sh.in > > INSTALL modules > > Makefilepltcl.c > > license.terms pltcl_guide.nr > > mkMakefile.tcldefs.sh test > > su-2.04# gmake > > Makefile:22: Makefile.tcldefs: No such file or directory > > /bin/sh ./mkMakefile.tcldefs.sh > > ^Cgmake: *** Deleting file `Makefile.tcldefs' > > gmake: *** [Makefile.tcldefs] Interrupt > > > > > > Jie LIANG > > > > St. Bernard Software > > > > 10350 Science Center Drive > > Suite 100, San Diego, CA 92121 > > Office:(858)320-4873 > > > > [EMAIL PROTECTED] > > www.stbernard.com > > www.ipinc.com > > > > > > > > > -- > 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])
Re: [HACKERS] ecpg long int problem on alpha + fix
Michael Meskes wrote: > > On Tue, Apr 03, 2001 at 06:32:25PM +0300, Adriaan Joubert wrote: > > we had a problem on Alpha that in interfaces/ecpg/lib/typename.c we > > have > > HAVE_LONG_INT_64 defined, but not HAVE_LONG_LONG_INT_64. Consequently no > > Sure since that means your long int and not your long long int is 64 bits. > > > code is included for long ints and typename calls *abort*. I put in a > > few lines that check for HAVE_LONG_INT_64 and seem to generate the right > > Why is this needed? What you do is use "long long" as variable type for 64 > bits integer. But on the alpha you do not need "long long", just use "long > int" instead. > > Or did I misunderstand something? OK, I see. Problem is that without the fix ecpg aborts when writing to a table with an int8 column using valid code. long int long long long long int all exist on alpha and are all 64 bits, but HAVE_LONG_LONG_INT_64 is not defined, so ecpg cannot handle ECPGt_long_long types. It is not clear to me what the best thing is to fix here -- possibly configure needs to set HAVE_LONG_LONG_INT_64 (which solves the problem on alpha as well), but I do not know what the consequences of that are. Cheers, Adriaan ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] RPMS for RC3
Uploaded. Please take a look. ftp://ftp.postgresql.org/pub/dev/test-rpms There _are_ changes. I will detail the changes for the RC4 RPMset. Karl's pl/perl changes will go into the next set. pg_dumplo will have a built binary, to be located in /usr/lib/pgsql/contrib. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(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] pg_dupp/pg_dumpall problem!
Hi! I've noticed a pg_dump/pg_dumpall problem with timestamp variables, in dumping the minute, and second values: instead of dumping 12:01:00.00 it dumps out 12:60:00.00 which is not accepted when restoring a database... Gyuro Lehel ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] release dates and announcements ?
We are just (as per other queries recently) building a new system using postgresql as the backend database. 7.1 seems like it is going give us a number of essential fixes and useful features that make it worth waiting a while. As I have not seen announcements of the beta and RC cuts on pgsql-announce, I would assume the development schedule is a more closed thing than general chatter here, BUT is there an target timetable for 7.1 (more that "when its ready" and subsequent 7.1.1 type releases ? This information would help us decide whether to use an RC as a development platform, moving to release later when we are ready to test final work. Also, would it be possible to announce alpha/beta/RC releases to pgsql-announce ? rgds, -- Peter Galbavy Knowledge Matters Ltd http://www.knowledge.com/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Re: libtcl
No, I was wrong in even mentioning libpgtcl. You don't even need that. pgmonitor does not connect to the database at any time. I should run as a shell script if you have tcl/tk >= 8.0 installed. > > What I need to do to install libtcl > > Do I still need to > createlang -d dbname pltcl?? > and when?? > > > Jie LIANG > > St. Bernard Software > > 10350 Science Center Drive > Suite 100, San Diego, CA 92121 > Office:(858)320-4873 > > [EMAIL PROTECTED] > www.stbernard.com > www.ipinc.com > > On Sat, 7 Apr 2001, Bruce Momjian wrote: > > > You don't need pltcl, just libtcl. > > > > > > > > I tried to intall pltcl, but failed when I tried to build a > > > pltcl.so > > > it seems hangging on there forever, what's wrong?? > > > > > > su-2.04# cd /work/src/pgsql702/src/pl/tcl/ > > > su-2.04# ls > > > CVS mkMakefile.tcldefs.sh.in > > > INSTALL modules > > > Makefilepltcl.c > > > license.terms pltcl_guide.nr > > > mkMakefile.tcldefs.sh test > > > su-2.04# gmake > > > Makefile:22: Makefile.tcldefs: No such file or directory > > > /bin/sh ./mkMakefile.tcldefs.sh > > > ^Cgmake: *** Deleting file `Makefile.tcldefs' > > > gmake: *** [Makefile.tcldefs] Interrupt > > > > > > > > > Jie LIANG > > > > > > St. Bernard Software > > > > > > 10350 Science Center Drive > > > Suite 100, San Diego, CA 92121 > > > Office:(858)320-4873 > > > > > > [EMAIL PROTECTED] > > > www.stbernard.com > > > www.ipinc.com > > > > > > > > > > > > > > > -- > > 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 > > > > -- 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 4: Don't 'kill -9' the postmaster
[HACKERS] Re: Final call for platform testing
On Tue, 3 Apr 2001 14:10:12 -0700, Nathan Myers alluded: > I saw three separate reports of successful builds on Linux 2.4.2 on x86 > (including mine), but it isn't listed here. [jeff@cairhien pronto]$ /var/postgresql/bin/psql -V psql (PostgreSQL) 7.1RC1 contains history support .. [jeff@cairhien pronto]$ uname -a Linux cairhien 2.4.3 #1 Tue Apr 3 01:08:19 EDT 2001 i686 unknown Jeff -- Jeff Duffy [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Re: RC3 ... and rpms...
Karl DeBisschop wrote: > Actually, since you can suppress installation of the docs with --nodocs, > I would very much prefer to keep the html and text docs in the main RPM. > Otherwise I have two directories in /usr/doc for one software suite. I'm researching how to get a subpackage to place docs in the main package %doc. HTML docs and man pages are with the main package; SGML source and any hardcopy docs will go into the docs subpackage. The contrib tree is getting its own subpackage. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
re: [lockhart@alumni.caltech.edu: [HACKERS] Third call for platform testing]
>> i will be reinstalling this SS20 with a full installation sometime in >> the next few days. i will re-run the testsuite after this to see if >> that is causing any of the lossage. Please let us know. actually, i had a classic i could test with -- all except horology passed, so if there were two expected failures there, all is fine on NetBSD/sparc. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] PL/pgSQL IDE project
Hello all, I would like to inform you all that I am currently working on the implementation of PL/pgSQL packages on both server-side (PostgreSQL 7.1) and client-side (PgAdmin). The idea is to add an PL/pgSQL Integrated Development Environment to pgadmin. Help and suggestions needed. If someone is already working on a similar project, let me know how I can help. For discussion, please register on mailto:[EMAIL PROTECTED] mailing list. Help and suggestions needed ! First of all, some useful resources: http://www.oreilly.com/catalog/advoracle/chapter/ch02.html http://postgresql.rmplc.co.uk/devel-corner/docs/programmer/plpgsql-porting.html The basic idea behind the project is to store functions and packages in PgAdmin tables and use drop/create mechanisms to load them in the database. Here is a first analysis, do not blame in case it is imprecise: 1) Dependencies The main problem when compiling a set of functions is dependencies : - transitivity dependencies: if function B relies on function B, and function A relies on function C, the compilation should be in A, B and C order. - cross dependencies: if a function A relies on B, B relies on C and C relies on A, compilation will not work. Warnings should be sent to the user. According to http://www.oreilly.com/catalog/advoracle/chapter/ch02.html, this problem exists in Oracle databases (!!!). To avoid simple dependency problems, we need to work on isolating compiling mechanisms. This could be something like : - functions with no sub calls are compiled first, - functions with sub calls are compiled secondly, according to an automatic dependency analysis, - triggers are compiled at last, - ultimately, users should be able to define compilation order. There are maybe more simple mechanisms (???). Does pg_dump isolate functions in a precise order (???). 2) Isolate Development / Production versions For every single function, we should isolate the production version (stable) from the development version (unstable). This will help debugging and solve dependencies until the project is 'cleanly' compiled and debugged. This can be done by renaming all functions with the 'unstable_' prefix during compilation and the use of aliases. Let's see the example with functionX : -> functionX is an alias that calls : stable_functionX (arg1, ...): stable version (production) unstable_functionX (arg1, ...): unstable version (development) serial1_functionX (arg1, ...), serial2_functionX (arg1, ...): archived versions of functionX Of course, this would be transparent for the developer which will only see functionX in the IDE. Switching from unstable_function to stable_function would only require to recompile the aliases. 3) Serialize package releases It should be possible to serialize packages and store/reload different releases. A logging table will provide a change log (with user names and description of changes). I do not intend to work on diffs and don't think it is possible. 4) Server-side logic Most of the logic should be developed in PL/pgSQL. On client-side, PgSchema (the new object structure of Pgadmin) will manage the whole thing. 5) Syntax checking / indenting. Has anyone heard of open-source objects handling code indenting and syntax checking ? I am not going to work on this, help needed. 6) Import / Export of packages We need a simple mechanism to import/export packages. 7) Master/Slave PL/pgSQL Server Code should be stored on a master server and distributed to slave servers through simple mechanisms. This last logic will be stored in PgSchema as I don't know how to do it with PostgreSQL itself. Any possibility to embed it in PostgreSQL (remote call ???). Looking forward to hearing from you, Greetings from Jean-Michel POURE, Paris ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
re: [lockhart@alumni.caltech.edu: [HACKERS] Third call for platform testing]
>> digging into the regression.diffs, i can see that: >> - reltime failed because it just had: >> ! psql: Backend startup failed The postmaster log file should have more info, but a first thought is that you ran up against process or swap-space limitations. The parallel check has fifty-odd processes going at its peak, which is more than the default per-user process limit on many Unixen. hmm, maxproc=80 on this system currently and i wasn't really doing anything else. it has 256MB ram and 280MB swap (unused). exactly what am i looking for in the postmaster.log file? it is 65kb long... ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Re: Integer to float function
On Fri, 06 April 2001, Tom Lane wrote: > > Thomas Lockhart <[EMAIL PROTECTED]> writes: > > Try using int2()/int4()/int8() instead of integer(). > >> Why is that NOT documented under "Matematical functions"? > > > Because we haven't received any patches to document it? ;) > > Or because it's not a mathematical function. I don't think that > datatype conversion functions belong under that heading. > > regards, tom lane I did not mean to question the position of integre() or int4(), or ... in the PostgreSQL documents. I HAVE found a list of functions, among them integer(), under mathematical functions and have NOT found anything about int4() or intn(), should I say. Perhaps, I was not searching the docs enough, but you know how we do things in a hurry - we do search the TOC. So, if there is intn() desribed somewhere in the docs, I apologise BUT there is not then we have a communication problem. Thanks in any case. The most important thing is that my migration from RedHat6.2/postgreSQL6.5 to Mandrake/PostgreSQL7.0.2 was easy and successfull, mostly because of this forum and questions/answers that we have in circulation. Cheers, Steven. _ iVillage.com: Solutions for Your Life Check out the most exciting women's community on the Web http://www.ivillage.com ---(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: [lockhart@alumni.caltech.edu: [HACKERS] Third call for platform testing]
matthew green <[EMAIL PROTECTED]> writes: > digging into the regression.diffs, i can see that: > - reltime failed because it just had: > ! psql: Backend startup failed >The postmaster log file should have more info, but a first thought is >that you ran up against process or swap-space limitations. The parallel >check has fifty-odd processes going at its peak, which is more than the >default per-user process limit on many Unixen. > hmm, maxproc=80 on this system currently and i wasn't really doing anything > else. it has 256MB ram and 280MB swap (unused). exactly what am i looking > for in the postmaster.log file? it is 65kb long... Look for messages about "fork failed". They should give a kernel error message too. after running `unlimit' (tcsh) before `make check', the only failures i have are the horology (expected) and the inherit sorted failures, on NetBSD/sparc64. i also believe the `Bad address' errors were caused when the test was run in an NFS mounted directory. .mrg. ---(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] Test results for postgresql-7.1RC2 on NetBSD/macppc 1.5
A friend of mine (Matthew Green) mentioned that 7.1RC2 had NetBSD/powerpc down as unttested, and asked me to test it. So here are the results: On my NetBSD/macppc system running NetBSD 1.5, gmake check reported that 2 of 62 tests failed. I've attached regression.diff to this message. The two that failed were geometry and horology. >From looking at the output, the horology test seemed to get confused about daylight savings time. The geometry test seems to be a difference in the last digit in two of the numbers: Expect: Got: -1.33012701887967 -1.33012701887966 0.5081028 0.5081027 Take care, Bill *** ./expected/geometry-positive-zeros.out Tue Sep 12 14:07:16 2000 --- ./results/geometry.out Thu Apr 5 03:04:38 2001 *** *** 445,451 -+- | ((-3,0),(-2.59807621135076,1.500442),(-1.499116,2.59807621135842),(1.53102359017709e-11,3),(1.501768,2.59807621134311),(2.59807621136607,1.49779),(3,-3.06204718035418e-11),(2.59807621133545,-1.503094),(1.496464,-2.59807621137373),(-4.59307077053127e-11,-3),(-1.50442,-2.5980762113278),(-2.59807621138138,-1.495138)) | ((-99,2),(-85.6025403783588,52.01473),(-48.97054,88.602540378614),(1.051034,102),(51.05893,88.6025403781036),(87.6025403788692,51.92634),(101,1.897932),(87.6025403778485,-48.10313),(50.88214,-84.6025403791243),(0.8468976,-98),(-49.14732,-84.6025403775933),(-85.6025403793795,-47.83795)) ! | ((-4,3),(-3.33012701891794,5.500737),(-1.498527,7.3301270189307),(1.002552,8),(3.502946,7.33012701890518),(5.33012701894346,5.496317),(6,2.994897),(5.33012701889242,0.4948437),(3.494107,-1.33012701895622),(0.9923449,-2),(-1.507366,-1.33012701887967),(-3.33012701896897,0.5081028)) | ((-2,2),(-1.59807621135076,3.500442),(-0.4991161,4.59807621135842),(1.001531,5),(2.501768,4.59807621134311),(3.59807621136607,3.49779),(4,1.996938),(3.59807621133545,0.4969062),(2.496464,-0.598076211373729),(0.9954069,-1),(-0.5044197,-0.598076211327799),(-1.59807621138138,0.5048616)) | ((90,200),(91.3397459621641,205.0015),(95.00295,208.660254037861),(100.0051,210),(105.0059,208.66025403781),(108.660254037887,204.9926),(110,199.9898),(108.660254037785,194.9897),(104.9882,191.339745962088),(99.98469,190),(94.98527,191.339745962241),(91.3397459620621,195.0162)) | ((0,0),(13.3974596216412,50.01473),(50.02946,86.602540378614),(100.051,100),(150.0589,86.6025403781036),(186.602540378869,49.92634),(200,-1.02068239345139e-09),(186.602540377848,-50.10313),(149.8821,-86.6025403791243),(99.8469,-100),(49.85268,-86.6025403775933),(13.3974596206205,-49.83795)) --- 445,451 -+- | ((-3,0),(-2.59807621135076,1.500442),(-1.499116,2.59807621135842),(1.53102359017709e-11,3),(1.501768,2.59807621134311),(2.59807621136607,1.49779),(3,-3.06204718035418e-11),(2.59807621133545,-1.503094),(1.496464,-2.59807621137373),(-4.59307077053127e-11,-3),(-1.50442,-2.5980762113278),(-2.59807621138138,-1.495138)) | ((-99,2),(-85.6025403783588,52.01473),(-48.97054,88.602540378614),(1.051034,102),(51.05893,88.6025403781036),(87.6025403788692,51.92634),(101,1.897932),(87.6025403778485,-48.10313),(50.88214,-84.6025403791243),(0.8468976,-98),(-49.14732,-84.6025403775933),(-85.6025403793795,-47.83795)) ! | ((-4,3),(-3.33012701891794,5.500737),(-1.498527,7.3301270189307),(1.002552,8),(3.502946,7.33012701890518),(5.33012701894346,5.496317),(6,2.994897),(5.33012701889242,0.4948437),(3.494107,-1.33012701895622),(0.
re: [lockhart@alumni.caltech.edu: [HACKERS] Third call for platform testing]
> >> CREATE INDEX hash_i4_index ON hash_i4_heap USING hash (random int4_ops); > >> + ERROR: cannot read block 3 of hash_i4_index: Bad address > > "Bad address"? That seems pretty bizarre. This is obviously something that shows up on _some_ NetBSD platforms. The above was on sparc64, but that same problem is the only one I see that Bad address message was actually from sparc. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[HACKERS] RPM upgrade caveats going from a beta version to RC
One quick note -- since 'R' < 'b', the RC RPM's must be forced to install with --oldpackage, as RPM does a simple strcmp of version numbers -- 7.1RC3 < 7.1beta1, for instance. Just force it with --oldpackage if you have a 7.1beta RPM already installed. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] Re: Debian packages of 7.1RC3
"Oliver Elphick" wrote: >Debian packages of 7.1RC3 have been uploaded to the Debian experimental >distribution and are also available at http://www.debian.org/~elphick/postgr >esql > >These packages are built for sid (Debian unstable); I am currently >trying to build a set for potato (stable). Packages for potato are now available from the same URL -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight http://www.lfix.co.uk/oliver PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47 GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C "I sought the Lord, and he answered me; he delivered me from all my fears." Psalm 34:4 ---(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] Debian packages of 7.1RC3
Debian packages of 7.1RC3 have been uploaded to the Debian experimental distribution and are also available at http://www.debian.org/~elphick/postgresq l These packages are built for sid (Debian unstable); I am currently trying to build a set for potato (stable). Incidentally, when the next release is done, could we have a more machine-friendly system of version naming? We started with 7.1beta, then went to 7.1RC and will finish with 7.1. These sort in reverse order to what is wanted! so I have to play games with the release names to get them to work with the Debian installer (7.1beta, 7.1cRC, 7.1final). Why not adopt the practice of making odd-numbered minor releases be development and even-numbered ones be stable? Name the final release of 7.1 as 7.2, go on with developing 7.3.x and finally release that as 7.4. -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight http://www.lfix.co.uk/oliver PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47 GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C "I sought the Lord, and he answered me; he delivered me from all my fears." Psalm 34:4 ---(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] release dates and announcements ?
Hi Peter ...
The problem this cycle has been that as soon as a package is ready
for announce, ppl have been cropping up with bugs that need to be fixed,
so we don't bother announcing it ... except to -hackers ...
We are currently at Release Candidate 3, with an RC4 most likely
going out tomorrow evening, which will also be announced to -announce as
the 'final release before release' ...
... and, if all goes well, the full relesae will be out on Friday
of this coming week ...
On Thu, 5 Apr 2001, Peter Galbavy wrote:
> We are just (as per other queries recently) building a new system
> using postgresql as the backend database. 7.1 seems like it is going
> give us a number of essential fixes and useful features that make it
> worth waiting a while.
>
> As I have not seen announcements of the beta and RC cuts on
> pgsql-announce, I would assume the development schedule is a more
> closed thing than general chatter here, BUT is there an target
> timetable for 7.1 (more that "when its ready" and subsequent 7.1.1
> type releases ?
>
> This information would help us decide whether to use an RC as a
> development platform, moving to release later when we are ready to
> test final work.
>
> Also, would it be possible to announce alpha/beta/RC releases to
> pgsql-announce ?
>
> rgds,
> --
> Peter Galbavy
> Knowledge Matters Ltd
> http://www.knowledge.com/
>
> ---(end of broadcast)---
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] A more useful way to split the distribution
On Sun, 08 Apr 2001 11:24, Peter Eisentraut wrote: > Since people suddenly seem to be suffering from bandwidth concerns I > have devised a new distribution split to address this issue. [ ... snipping the many tarballs argument ... ] For me and I expect many other folk on the edge of civilization it is a total PITA to have to fiddle around and download many separate tarball files. What I want is to be able to start a d/l going and then come back when it's finished and know that I have _everything_ I actually need to have a working and documented product in one shot. For developers, contributors and testers and I would like to suggest that an exact snapshot of the complete CVS source archive is appropriate. We can then track the changes every day using cvs or cvsup - wonderful tool btw - What is really _really_ needed is a text README which explains exactly what file contains. Personally I have found that the limitations of the packaging systems to be such a nuisence that I always compile everything from source. -- Sincerely etc., NAME Christopher Sawtell CELL PHONE 021 257 4451 ICQ UIN45863470 EMAIL csawtell @ xtra . co . nz CNOTES ftp://ftp.funet.fi/pub/languages/C/tutorials/sawtell_C.tar.gz -->> Please refrain from using HTML or WORD attachments in e-mails to me <<-- ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[HACKERS] RC3-3 RPMS.
Are up. Contrib subpackage includes built binaries. Binary RPMset built for _Red_Hat_6.2_. I will be building Red Hat 7.0 RPMS after I get back from a two day vacation -- which will put me back online Wednesday. I might get a set out for RH7 tomorrow, though. The split to contrib and docs subpackages has greatly reduced the size of the main client RPM down to a little over 1MB. The contrib subpackage is nearly a meg, as is the docs subpackage (which as yet doesn't have the hardcopy docs). Also, I would love it to see jars of the 7.1 JDBC built in the near future, as I _still_ don't have a good JDK on any of my devel boxen -- meaning I'm still shipping the 7.0 JDBC in the jdbc subpackage. ftp://ftp.postgresql.org/pub/dev/test-rpms,as usual. See README.rpm-dist in the main package for more details, as it is actually up to date at this time. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(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] RPM upgrade caveats going from a beta version to RC
On Sat, 7 Apr 2001, Lamar Owen wrote: > One quick note -- since 'R' < 'b', the RC RPM's must be forced to > install with --oldpackage, as RPM does a simple strcmp of version > numbers -- 7.1RC3 < 7.1beta1, for instance. Just force it with > --oldpackage if you have a 7.1beta RPM already installed. Huh? I always thought that ASCII R was greater then b ... *confused* in the future, would it help to have 7.2Beta? Or am I missing something? :) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
