Re: [PATCHES] Warning for missing createlang
Bruce Momjian wrote: > I have written a patch to issue an hint if someone tries to create a > function in a language that isn't loaded into the database: > > test=> CREATE FUNCTION xx() RETURNS INT AS ' > test'> select 1' > test-> LANGUAGE 'plpgsql'; > ERROR: language "plpgsql" does not exist > HINT: Perhaps you need to use 'createlang' to load the language into > the database. > > I know Peter didn't like this idea in the past, but we are getting too > many people who forget createlang, and with our new HINT tags, it seems > appropriate. OK, Peter and Tom don't like it. :-( How about this, that also suggests you mistyped the name: > HINT: Perhaps you need to use 'createlang' to load the language into > the database, or you mistyped the language name. ^ -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] small typos
Patch applied. Thanks. --- Alvaro Herrera wrote: > Patchers, > > This fixes three minor typos in hba.c. > > -- > Alvaro Herrera () > "There was no reply" (Kernel Traffic) [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 8: explain analyze is your friend -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[PATCHES] fix doc typo
This patch fixes a trivial typo in the CREATE FUNCTION ref page. -Neil Index: doc/src/sgml/ref/create_function.sgml === RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/ref/create_function.sgml,v retrieving revision 1.49 diff -c -r1.49 create_function.sgml *** doc/src/sgml/ref/create_function.sgml 31 Aug 2003 17:32:22 - 1.49 --- doc/src/sgml/ref/create_function.sgml 5 Sep 2003 03:10:10 - *** *** 379,385 Examples !Here is a trivial example to help you get startet. For more information and examples, see . CREATE FUNCTION add(integer, integer) RETURNS integer --- 379,385 Examples !Here is a trivial example to help you get started. For more information and examples, see . CREATE FUNCTION add(integer, integer) RETURNS integer ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] doc patch - linux memory handling
Patch applied. Thanks. --- Andrew Dunstan wrote: > > It appears we are back in the "you need a non-empty password" mode. > > Anyway, here's the revised patch. > > andrew > > > Andrew Dunstan wrote: > > > > > I didn't find a single instance of a tag in the doc sources. > > I did find a warning in an unadorned para, in func.sgml. > > > > Anyway, I made the changes (using ) but anoncvs is now refusing > > my login attempt, so I can't do the diff. > > > > I've spent way too much time on this already - really my only concern > > was that the docs would give people info that would make things worse > > rather than better, and nobody else was doing anything about it. > > > > cheers > > > > andrew > > > > Index: doc/src/sgml/runtime.sgml > === > RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/runtime.sgml,v > retrieving revision 1.200 > diff -c -w -r1.200 runtime.sgml > *** doc/src/sgml/runtime.sgml 17 Aug 2003 22:19:10 - 1.200 > --- doc/src/sgml/runtime.sgml 22 Aug 2003 16:14:47 - > *** > *** 3068,3081 > > > > ! Linux has poor default memory overcommit behavior. Rather than > ! failing if it can not reserve enough memory, it returns success, > ! but later fails when the memory can't be mapped and terminates > ! the application with kill -9. To prevent unpredictable > ! process termination, use: > > sysctl -w vm.overcommit_memory=3 > > Note, you will need enough swap space to cover all your memory needs. > > > --- 3068,3128 > > > > ! Linux kernel version 2.4.* has poor default memory overcommit > ! behavior, which can result in the postmaster being killed by the > ! kernel due to memory demands by another process if the system > ! runs out of memory. > ! > ! > ! > ! The symptom of this occuring is a kernel message looking like > ! this (consult your system documentation and configuration on > ! where to look for such a message): > ! > ! Out of Memory: Killed process 12345 (postmaster). > ! > ! > ! > ! > ! To avoid this situation, run PostgreSQL > ! on a machine where you > ! can be sure that other processes will not run the machine out > ! of memory. If your kernel supports strict and/or paranoid modes > ! of overcommit handling, you can also relieve this problem by > ! altering the system's default behaviour. This can be determined > ! by examining the function vm_enough_memory > ! in the file mm/mmap.cin the kernel source. > ! If this file reveals that strict and/or paranoid modes are > ! supported by your kernel, turn one of these modes on by using > ! > ! sysctl -w vm.overcommit_memory=2 > ! > ! for strict mode or > > sysctl -w vm.overcommit_memory=3 > > + for paranoid mode, or placing an equivalent entry in > + /etc/sysctl.conf. > + > + > + > + > + Warning: using these settings in a kernel which does not support > + these modes will almost certainly increase the danger of the > + kernel killing the postmaster, rather than reducing it. > + If in any doubt, consult a kernel expert or your kernel vendor. > + > + > + > + > + These modes are expected to be supported in all 2.6 and later > + kernels. Some vendor 2.4 kernels may also support these modes. > + However, it is known that some vendor documents suggest that > + they support them while examination of the kernel source reveals > + that they do not. > + > + > + > Note, you will need enough swap space to cover all your memory needs. > > > > ---(end of broadcast)--- > TIP 7: don't forget to increase your free space map settings -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [PATCHES] postgresql-7.4b1 Native-Windows patch
I went over this patch and fixed the problem with WIN32_CONSOLE. It seems you have a problem with mbvalidate. Is that correct? What doesn't work there? Also, I see you had to ifdef out something in thread.c. Would you test current CVS and see if you still need that change. Thanks. --- Hiroshi Saito wrote: > Hi Bruce. > > Current 7.4b1 can't be made with Native-Windows. > This wasn't necessarily investigated in detail. > It was modified because first of all I wanted to use it. > psql.exe works in this. > > Take it into consideration as an information though it thinks whether it is > during the progress. > > Regards, > Hiroshi Saito [ Attachment, skipping... ] -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] libpq-win32 patches
OK, I have applied this patch, except for this part:
> Index: include/pg_config.h.win32
> ===
> RCS file: /projects/cvsroot/pgsql-server/src/include/pg_config.h.win32,v
> retrieving revision 1.11
> diff -u -r1.11 pg_config.h.win32
> --- include/pg_config.h.win32 12 Jun 2003 08:15:29 - 1.11
> +++ include/pg_config.h.win32 31 Aug 2003 23:22:31 -
> @@ -60,4 +60,9 @@
> #include
> #endif
>
> +#include
> +
> +/* getpwuid doesn't exist under win32 */
> +#define getpwuid(uid) NULL
> +
> #endif /* pg_config_h_win32__ */
Why was this needed? I realize we don't have getpwuid() on Win32, but
we do have GetUserName() for cases where we need the name but not the
directory.
Because all the getpwuid() calls seem ifdef'ed out under Win32 anyway, I
don't understand why you needed it.
---
Andreas Pflug wrote:
> Hm,
>
> I don't see any reaction on my posts from last sunday, neither in this
> list nor in unapplied patches, did they get lost?
> If so, attached is a combined patch for all three problems with libpq
> compiling under win32.
>
> Regards,
> Andreas
>
> cvs diff -u interfaces\libpq\fe-connect.c interfaces\libpq\fe-exec.c
> interfaces\libpq\fe-secure.c interfaces\libpq\libpq-int.h include\pg_config.h.win32
> interfaces\libpq\win32.c interfaces\libpq\win32.mak (in directory C:\postgresql\src\)
> Index: interfaces/libpq/fe-connect.c
> ===
> RCS file: /projects/cvsroot/pgsql-server/src/interfaces/libpq/fe-connect.c,v
> retrieving revision 1.259
> diff -u -r1.259 fe-connect.c
> --- interfaces/libpq/fe-connect.c 4 Aug 2003 02:40:16 - 1.259
> +++ interfaces/libpq/fe-connect.c 31 Aug 2003 23:22:25 -
> @@ -48,7 +48,7 @@
>
> /* For FNCTL_NONBLOCK */
> #if defined(WIN32) || defined(__BEOS__)
> -long ioctlsocket_ret;
> +long ioctlsocket_ret=1;
> #endif
>
> #define PGPASSFILE ".pgpass"
>
> Index: interfaces/libpq/fe-exec.c
> ===
> RCS file: /projects/cvsroot/pgsql-server/src/interfaces/libpq/fe-exec.c,v
> retrieving revision 1.146
> diff -u -r1.146 fe-exec.c
> --- interfaces/libpq/fe-exec.c27 Aug 2003 00:33:34 - 1.146
> +++ interfaces/libpq/fe-exec.c31 Aug 2003 23:22:28 -
> @@ -2304,7 +2304,7 @@
> if (buffer == NULL)
> return NULL;
>
> - for (i = j = buflen = 0; i < strtextlen;)
> + for (i = j = buflen = 0; i < (int)strtextlen;)
> {
> switch (strtext[i])
> {
> Index: interfaces/libpq/fe-secure.c
> ===
> RCS file: /projects/cvsroot/pgsql-server/src/interfaces/libpq/fe-secure.c,v
> retrieving revision 1.29
> diff -u -r1.29 fe-secure.c
> --- interfaces/libpq/fe-secure.c 4 Aug 2003 17:25:14 - 1.29
> +++ interfaces/libpq/fe-secure.c 31 Aug 2003 23:22:29 -
> @@ -312,7 +312,7 @@
> printfPQExpBuffer(&conn->errorMessage,
>
> libpq_gettext("SSL SYSCALL error: EOF detected\n"));
>
> - SOCK_ERRNO = ECONNRESET;
> + SOCK_ERRNO_SET(ECONNRESET);
> n = -1;
> }
> break;
> @@ -322,7 +322,7 @@
> libpq_gettext("SSL error: %s\n"),
> SSLerrmessage());
> /* fall through */
> case SSL_ERROR_ZERO_RETURN:
> - SOCK_ERRNO = ECONNRESET;
> + SOCK_ERRNO_SET(ECONNRESET);
> n = -1;
> break;
> default:
> @@ -383,7 +383,7 @@
> {
> printfPQExpBuffer(&conn->errorMessage,
>
> libpq_gettext("SSL SYSCALL error: EOF detected\n"));
> - SOCK_ERRNO = ECONNRESET;
> + SOCK_ERRNO_SET(ECONNRESET);
> n = -1;
> }
> break;
> @@ -393,7 +393,7 @@
> libpq_gettext("SSL error: %s\n"),
> SSLerrmessage());
> /* fall through */
> case SSL_ERROR_ZERO_RETURN:
> - SOCK_ERRNO = ECONNRESET;
> + SOCK_ERR
Re: [PATCHES] libpq with ssl under win32
Andreas Pflug wrote: > The attached patch enables libpq to be linked with ssl support (openssl > 0.9.7.b tested). > Client certificates are commented out because the implementation is *nix > specific, regarding the location resolution of the .pem files. It needs > to be discussed where these files should be located. For NT/W2K and up, > the natural way would be using GetUserProfileDirectory, but this would > exclude Win9x. Can't we check the OS version via the compiler? Maybe not portabily between the various compilers supported. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] Warning for missing createlang
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > I have written a patch to issue an hint if someone tries to create a > > function in a language that isn't loaded into the database: > > > ERROR: language "plpgsql" does not exist > > HINT: Perhaps you need to use 'createlang' to load the language into > > the database. > > > I know Peter didn't like this idea in the past, but we are getting too > > many people who forget createlang, and with our new HINT tags, it seems > > appropriate. > > I still agree with Peter's opinion ... this hint is fairly silly, > especially since it would pop out for simple misspellings of language > names. What can we do to help people remember they have forgotten to load the language? The post that question here too often. I don't see any problem with a hint that starts with "Perhaps". -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [PATCHES] Warning for missing createlang
Bruce Momjian <[EMAIL PROTECTED]> writes: > I have written a patch to issue an hint if someone tries to create a > function in a language that isn't loaded into the database: > ERROR: language "plpgsql" does not exist > HINT: Perhaps you need to use 'createlang' to load the language into > the database. > I know Peter didn't like this idea in the past, but we are getting too > many people who forget createlang, and with our new HINT tags, it seems > appropriate. I still agree with Peter's opinion ... this hint is fairly silly, especially since it would pop out for simple misspellings of language names. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] IPV4 addresses on IPV6 machines in pg_hba.conf
Andreas,
You should check that the CIDR mask is a valid integer. You would need
to use strtol() rather than atoi() to do that. Perhaps this should be
hoisted out of ip.c:SockAddr_cidr_mask() and put in hba.c.
Sorry, I should have checked this carefully earlier.
andrew
Andreas Pflug wrote:
Kurt Roeckx wrote:
You're assuming all systems have an AF_INET6 constant, which is
not the case. Please make use of HAVE_IPV6.
Can't directly see anything else wrong with it.
Here's the patch with HAVE_IPV6 conditional compiling.
Regards,
Andreas
Index: hba.c
===
RCS file: /projects/cvsroot/pgsql-server/src/backend/libpq/hba.c,v
retrieving revision 1.111
diff -c -r1.111 hba.c
*** hba.c 4 Aug 2003 02:39:59 - 1.111
--- hba.c 5 Sep 2003 00:24:47 -
***
*** 673,708
if (cidr_slash)
*cidr_slash = '/';
! if (file_ip_addr->ai_family != port->raddr.addr.ss_family)
{
! /* Wrong address family. */
freeaddrinfo_all(hints.ai_family, file_ip_addr);
! return;
}
! /* Get the netmask */
! if (cidr_slash)
{
! if (SockAddr_cidr_mask(&mask, cidr_slash + 1,
! file_ip_addr->ai_family) < 0)
! goto hba_syntax;
}
else
{
! /* Read the mask field. */
! line = lnext(line);
! if (!line)
! goto hba_syntax;
! token = lfirst(line);
!
! ret = getaddrinfo_all(token, NULL, &hints, &file_ip_mask);
! if (ret || !file_ip_mask)
! goto hba_syntax;
!
! mask = (struct sockaddr_storage *) file_ip_mask->ai_addr;
!
! if (file_ip_addr->ai_family != mask->ss_family)
! goto hba_syntax;
}
/* Read the rest of the line. */
--- 673,767
if (cidr_slash)
*cidr_slash = '/';
! #ifdef HAVE_IPV6
!
! if (file_ip_addr->ai_family == AF_INET && port->raddr.addr.ss_family == AF_INET6)
{
! /* port got a IPV6 address, but the current line is IPV4.
! * We'll make a IPV6 entry from this line, to check if by chance the connecting port
! * is a converted IPV4 address. */
!
! char *v6addr=palloc(strlen(token)+8);
! char *v6mask;
!
freeaddrinfo_all(hints.ai_family, file_ip_addr);
!
! if (cidr_slash)
! *cidr_slash = 0;
! sprintf(v6addr, ":::%s", token);
! if (cidr_slash)
! *cidr_slash = '/';
!
! ret = getaddrinfo_all(v6addr, NULL, &hints, &file_ip_addr);
! if (ret || !file_ip_addr)
! {
! ereport(LOG,
! (errcode(ERRCODE_CONFIG_FILE_ERROR),
! errmsg("could not interpret converted IP address \"%s\" in config file: %s",
! token, gai_strerror(ret;
! }
! if (cidr_slash)
! {
! v6mask = palloc(20);
! sprintf(v6mask, "%d", atoi(cidr_slash+1)+96);
! if (SockAddr_cidr_mask(&mask, v6mask, file_ip_addr->ai_family) < 0)
! goto hba_syntax;
! }
! else
! {
! line = lnext(line);
! if (!line)
! goto hba_syntax;
! token = lfirst(line);
! v6mask = palloc(strlen(token)+32);
! sprintf(v6mask, "::::::%s", token);
!
! ret = getaddrinfo_all(v6mask, NULL, &hints, &file_ip_mask);
! if (ret || !file_ip_mask)
! goto hba_syntax;
!
! mask = (struct sockaddr_storage *) file_ip_mask->ai_addr;
!
! if (file_ip_addr->ai_family != mask->ss_family)
! goto hba_syntax;
! }
}
+ else
+
+ #endif // HAVE_IPV6
! if (file_ip_addr->ai_family != port->raddr.addr.ss_family)
{
! /* Wrong address family. */
! freeaddrinfo_all(hints.ai_family, file_ip_addr);
! return;
}
else
{
! /* Get the netmask */
! if (cidr_slash)
! {
! if (SockAddr_cidr_mask(&mask, cidr_slash + 1,
! file_ip_addr->ai_family) < 0)
! goto hba_syntax;
! }
! else
! {
! /* Read the mask field. */
! line = lnext(line);
! if (!line)
! goto hba_syntax;
! token = lfirst(line);
!
! ret = getaddrinfo_all(token, NULL, &hints, &file_ip_mask);
! if (ret || !file_ip_mask)
! goto hba_syntax;
!
! mask = (struct sockaddr_storage *) file_ip_mask->ai_addr;
!
! if (file_ip_addr->ai_family != mask->ss_family)
! goto hba_syntax;
! }
}
/* Read the rest of the line. */
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] IPV4 addresses on IPV6 machines in pg_hba.conf
Kurt Roeckx wrote:
You're assuming all systems have an AF_INET6 constant, which is
not the case. Please make use of HAVE_IPV6.
Can't directly see anything else wrong with it.
Here's the patch with HAVE_IPV6 conditional compiling.
Regards,
Andreas
Index: hba.c
===
RCS file: /projects/cvsroot/pgsql-server/src/backend/libpq/hba.c,v
retrieving revision 1.111
diff -c -r1.111 hba.c
*** hba.c 4 Aug 2003 02:39:59 - 1.111
--- hba.c 5 Sep 2003 00:24:47 -
***
*** 673,708
if (cidr_slash)
*cidr_slash = '/';
! if (file_ip_addr->ai_family != port->raddr.addr.ss_family)
{
! /* Wrong address family. */
freeaddrinfo_all(hints.ai_family, file_ip_addr);
! return;
}
! /* Get the netmask */
! if (cidr_slash)
{
! if (SockAddr_cidr_mask(&mask, cidr_slash + 1,
!
file_ip_addr->ai_family) < 0)
! goto hba_syntax;
}
else
{
! /* Read the mask field. */
! line = lnext(line);
! if (!line)
! goto hba_syntax;
! token = lfirst(line);
!
! ret = getaddrinfo_all(token, NULL, &hints, &file_ip_mask);
! if (ret || !file_ip_mask)
! goto hba_syntax;
!
! mask = (struct sockaddr_storage *) file_ip_mask->ai_addr;
!
! if (file_ip_addr->ai_family != mask->ss_family)
! goto hba_syntax;
}
/* Read the rest of the line. */
--- 673,767
if (cidr_slash)
*cidr_slash = '/';
! #ifdef HAVE_IPV6
!
! if (file_ip_addr->ai_family == AF_INET && port->raddr.addr.ss_family
== AF_INET6)
{
! /* port got a IPV6 address, but the current line is IPV4.
! * We'll make a IPV6 entry from this line, to check if by chance the
connecting port
! * is a converted IPV4 address. */
!
! char *v6addr=palloc(strlen(token)+8);
! char *v6mask;
!
freeaddrinfo_all(hints.ai_family, file_ip_addr);
!
! if (cidr_slash)
! *cidr_slash = 0;
! sprintf(v6addr, ":::%s", token);
! if (cidr_slash)
! *cidr_slash = '/';
!
! ret = getaddrinfo_all(v6addr, NULL, &hints, &file_ip_addr);
! if (ret || !file_ip_addr)
! {
! ereport(LOG,
! (errcode(ERRCODE_CONFIG_FILE_ERROR),
!errmsg("could not interpret converted
IP address \"%s\" in config file: %s",
! token,
gai_strerror(ret;
! }
! if (cidr_slash)
! {
! v6mask = palloc(20);
! sprintf(v6mask, "%d", atoi(cidr_slash+1)+96);
! if (SockAddr_cidr_mask(&mask, v6mask,
file_ip_addr->ai_family) < 0)
! goto hba_syntax;
! }
! else
! {
! line = lnext(line);
! if (!line)
! goto hba_syntax;
! token = lfirst(line);
! v6mask = palloc(strlen(token)+32);
! sprintf(v6mask, "::::::%s",
token);
!
! ret = getaddrinfo_all(v6mask, NULL, &hints,
&file_ip_mask);
! if (ret || !file_ip_mask)
! goto hba_syntax;
!
! mask = (struct sockaddr_storage *)
file_ip_mask->ai_addr;
!
! if (file_ip_addr->ai_family != mask->ss_family)
! goto hba_syntax;
! }
}
+ else
+
+ #endif // HAVE_IPV6
! if (file_ip_addr->ai_family != port->raddr.addr.ss_family)
{
! /* Wrong address family. */
! freeaddrinfo_all(hints.ai_family, file_ip_add
[PATCHES] minor documentation improvements
This patch makes a few minor improvements to the docs: make the conventions more consistent, and improve the ANALYZE ref page. -Neil Index: doc/src/sgml/perform.sgml === RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/perform.sgml,v retrieving revision 1.31 diff -c -r1.31 perform.sgml *** doc/src/sgml/perform.sgml 31 Aug 2003 17:32:19 - 1.31 --- doc/src/sgml/perform.sgml 5 Sep 2003 00:15:21 - *** *** 603,609 PostgreSQL planner will switch from exhaustive search to a genetic probabilistic search through a limited number of possibilities. (The switch-over threshold is !set by the geqo_threshold run-time parameter.) The genetic search takes less time, but it won't necessarily find the best possible plan. --- 603,609 PostgreSQL planner will switch from exhaustive search to a genetic probabilistic search through a limited number of possibilities. (The switch-over threshold is !set by the GEQO_THRESHOLD run-time parameter.) The genetic search takes less time, but it won't necessarily find the best possible plan. Index: doc/src/sgml/plpgsql.sgml === RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/plpgsql.sgml,v retrieving revision 1.22 diff -c -r1.22 plpgsql.sgml *** doc/src/sgml/plpgsql.sgml 3 Sep 2003 22:17:07 - 1.22 --- doc/src/sgml/plpgsql.sgml 5 Sep 2003 00:11:49 - *** *** 1350,1356 allow users to allow users to define set-returning functions that do not have this limitation. Currently, the point at which data begins being written to disk is controlled by the !sort_mem configuration variable. Administrators who have sufficient memory to store larger result sets in memory should consider increasing this parameter. --- 1350,1356 allow users to allow users to define set-returning functions that do not have this limitation. Currently, the point at which data begins being written to disk is controlled by the !SORT_MEM configuration variable. Administrators who have sufficient memory to store larger result sets in memory should consider increasing this parameter. Index: doc/src/sgml/ref/analyze.sgml === RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/ref/analyze.sgml,v retrieving revision 1.13 diff -c -r1.13 analyze.sgml *** doc/src/sgml/ref/analyze.sgml 31 Aug 2003 17:32:21 - 1.13 --- doc/src/sgml/ref/analyze.sgml 5 Sep 2003 00:02:12 - *** *** 28,37 Description !ANALYZE collects statistics about the contents of !tables in the database, and stores the results in !the system table pg_statistic. Subsequently, !the query planner uses the statistics to help determine the most efficient execution plans for queries. --- 28,37 Description !ANALYZE collects statistics about the contents !of tables in the database, and stores the results in the system !table pg_statistic. Subsequently, the query !planner uses these statistics to help determine the most efficient execution plans for queries. *** *** 105,153 !Unlike VACUUM FULL, !ANALYZE requires !only a read lock on the target table, so it can run in parallel with !other activity on the table. !For large tables, ANALYZE takes a random sample of the !table contents, rather than examining every row. This allows even very !large tables to be analyzed in a small amount of time. Note, however, !that the statistics are only approximate, and will change slightly each !time ANALYZE is run, even if the actual table contents !did not change. This may result in small changes in the planner's !estimated costs shown by EXPLAIN. !The collected statistics usually include a list of some of the most common !values in each column and a histogram showing the approximate data !distribution in each column. One or both of these may be omitted if !ANALYZE deems them uninteresting (for example, in !a unique-key column, there are no common values) or if the column !data type does not support the appropriate operators. There is more !information about the statistics in . The extent of analysis can be controlled by adjusting the !default_statistics_target parameter variable, or on a !column-by-column basis by setting the per-column !statistics target with ALTER TABLE ... ALTER COLUMN ... SET !STATISTICS (see !). The !target value sets the maximum number of entries in the most-common-value !list and the maximum number of bins in the histogram. The default !targ
[PATCHES] Warning for missing createlang
I have written a patch to issue an hint if someone tries to create a
function in a language that isn't loaded into the database:
test=> CREATE FUNCTION xx() RETURNS INT AS '
test'> select 1'
test-> LANGUAGE 'plpgsql';
ERROR: language "plpgsql" does not exist
HINT: Perhaps you need to use 'createlang' to load the language into
the database.
I know Peter didn't like this idea in the past, but we are getting too
many people who forget createlang, and with our new HINT tags, it seems
appropriate.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
Index: src/backend/commands/functioncmds.c
===
RCS file: /cvsroot/pgsql-server/src/backend/commands/functioncmds.c,v
retrieving revision 1.33
diff -c -c -r1.33 functioncmds.c
*** src/backend/commands/functioncmds.c 4 Aug 2003 02:39:58 - 1.33
--- src/backend/commands/functioncmds.c 4 Sep 2003 23:08:06 -
***
*** 437,443
if (!HeapTupleIsValid(languageTuple))
ereport(ERROR,
(errcode(ERRCODE_UNDEFINED_OBJECT),
!errmsg("language \"%s\" does not exist",
languageName)));
languageOid = HeapTupleGetOid(languageTuple);
languageStruct = (Form_pg_language) GETSTRUCT(languageTuple);
--- 437,444
if (!HeapTupleIsValid(languageTuple))
ereport(ERROR,
(errcode(ERRCODE_UNDEFINED_OBJECT),
!errmsg("language \"%s\" does not exist",
languageName),
!errhint("Perhaps you need to use 'createlang' to load
the language into the database.")));
languageOid = HeapTupleGetOid(languageTuple);
languageStruct = (Form_pg_language) GETSTRUCT(languageTuple);
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
[PATCHES] note on dropped columns in pg_attribute
I didn't see it documented anywhere that a 0 in attypid of pg_attribute,
and given the note on the need to match pg_type lest failure seems to
warrant the mention.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
Index: src/include/catalog/pg_attribute.h
===
RCS file: /projects/cvsroot/pgsql-server/src/include/catalog/pg_attribute.h,v
retrieving revision 1.104
diff -c -r1.104 pg_attribute.h
*** src/include/catalog/pg_attribute.h 4 Aug 2003 02:40:11 - 1.104
--- src/include/catalog/pg_attribute.h 4 Sep 2003 22:30:44 -
***
*** 50,56
* defines the data type of this attribute (e.g. int4). Information
* in that instance is redundant with the attlen, attbyval, and
* attalign attributes of this instance, so they had better match or
! * Postgres will fail.
*/
Oid atttypid;
--- 50,57
* defines the data type of this attribute (e.g. int4). Information
* in that instance is redundant with the attlen, attbyval, and
* attalign attributes of this instance, so they had better match or
! * Postgres will fail. An entry of 0 signifies a dropped column and
! * will have no match.
*/
Oid atttypid;
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] Fw: New translation
Mirko Tebaldi writes: > what about this email ? Can you send the files in a less unusual archive format? -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[PATCHES] OffsetNumber offnum (LOCKTAG in lock.c)
the offnum of LOCKTAG I gather indicates which row (tuple) is being locked in a row level locking. But when I lock 2 diffrent rows of a table, offset for both is 0. and also offset is 0 if i take a table lock on the same table. (blkno is the same for all three locks)..shouldnt the OffsetNumber offnum be different for each individual row lociked? if not, then what field of LOCKTAG recognizes each individual row (tuple) locked? thanks! ---(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
[PATCHES] PgSQL74b2: initdb fails (max_connections)
On FreeBSD 5.1 using PgSQL 7.4b2 initdb failed with: su-2.05b$ ./initdb -D /data/pgsql The files belonging to this database system will be owned by user "postgres". This user must also own the server process. The database cluster will be initialized with locale C. fixing permissions on existing directory /data/pgsql... ok creating directory /data/pgsql/base... ok creating directory /data/pgsql/global... ok creating directory /data/pgsql/pg_xlog... ok creating directory /data/pgsql/pg_clog... ok selecting default shared_buffers... 1000 selecting default max_connections... 40 creating configuration files... ok creating template1 database in /data/pgsql/base/1... ./postgres -boot -x1 -F -D/data/pgsql template1 FATAL: could not create semaphores: No space left on device DETAIL: Failed syscall was semget(4, 17, 03600). HINT: This error does *not* mean that you have run out of disk space. It occurs when either the system limit for the maximum number of semaphore sets (SEMMNI), or the system wide maximum number of semaphores (SEMMNS), would be exceeded. You need to raise the respective kernel parameter. Alternatively, reduce PostgreSQL's consumption of semaphores by reducing its max_connections parameter (currently 100). The PostgreSQL documentation contains more information about configuring your system for PostgreSQL. initdb: failed Why does initdb use max_connections=100, but "selecting default max_connections" gives 40 ? This patch solves the problem: --- initdb.orig Wed Sep 3 09:49:01 2003 +++ initdb Wed Sep 3 09:50:38 2003 @@ -575,7 +575,7 @@ break fi done - +PGSQL_OPT="$PGSQL_OPT -c max_connections=$nconns" echo "$nconns" ## Regards, -- Janko Richter ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] IPV4 addresses on IPV6 machines in pg_hba.conf
On Wed, Sep 03, 2003 at 07:19:16PM +0200, Andreas Pflug wrote: > This was discussed in [HACKERS] TCP/IP with 7.4 beta2 broken? > > > I created a patch to hba.c which uses IPV4 entries as IPV6 entries if > running on a IPV6 system (which is detected from a port coming in as > AF_INET6). > You're assuming all systems have an AF_INET6 constant, which is not the case. Please make use of HAVE_IPV6. Can't directly see anything else wrong with it. Kurt ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
