[PATCHES] There are any version that works on Windows 2000

2004-11-21 Thread ctnan
There is no way to install PostgreSQL 8.0.0 Beta4 and any other version
in my windows 2000. No matter what user i use or any kind of configuration
option combination it's allways the same.

I start the instalation and in the moment that the instalation said:


Activating procedural languages...

it throws this error:
@
Failed to connect to the database. Procedural languages files are installed.
but are not activated in any database.

server closed the connection unexpectedly
This probably means the server terminated abnormaliy before or while
processing
the request.
@

any way i accept the messages and go on but the installer said

@
Activating contrib modules...

and throws another error:
@
Failed to connect to the database. Contrib files are installed, but are
not activated in eny databases.

server closed the connection unexpectedly
This probably means the server terminated abnormaliy before or while
processing
the request.
@

I don't know if i'm doing something wrong but the installation coudn't be
that dificult.

It seams to be a joke nothing works well in any version of windows installation.

Please if i'm doing something wrong say it to me couse im turning green.

Sorry for ungry words but i have another concept about Postgres
I wish i'm wrong about this.

Thanks of all


---(end of broadcast)---
TIP 8: explain analyze is your friend


Re: [PATCHES] Unicode characters above 0x10000 #2

2004-11-21 Thread John Hansen
Updated patch, Disregard old one, it broke ucs2.


... John


cvs.diff
Description: cvs.diff

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html


Re: [PATCHES] Unicode characters above 0x10000 #2

2004-11-21 Thread John Hansen
3 times lucky?

Last one broke utf8 G

This one works, Too tired, sorry for the inconvenience..

... John


cvs.diff
Description: cvs.diff

---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match


Re: [PATCHES] There are any version that works on Windows 2000

2004-11-21 Thread Alvaro Herrera
On Thu, Nov 18, 2004 at 03:36:30PM -0300, [EMAIL PROTECTED] wrote:
 There is no way to install PostgreSQL 8.0.0 Beta4 and any other version
 in my windows 2000. No matter what user i use or any kind of configuration
 option combination it's allways the same.

There is certainly lots of people who has succesfully tested 8.0beta4 on
Win2k.  Something local to your installation is probably making it fail;
have you read the installer FAQ?

-- 
Alvaro Herrera ([EMAIL PROTECTED])
Escucha y olvidarás; ve y recordarás; haz y entenderás (Confucio)

---(end of broadcast)---
TIP 8: explain analyze is your friend


Re: [PATCHES] [HACKERS] New compile warnings

2004-11-21 Thread Andrew Dunstan

Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
 

I am seeing the following compile warnings in CVS. I am using for perl:
	Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration:
   

I believe these two:
 

plperl.c:948: warning: `ret_hv' might be used uninitialized in this function
plperl.c:949: warning: `ret_av' might be used uninitialized in this function
   

indicate an actual bug --- at least, it's far from clear that the code
can't try to use an uninitialized value.  I trust that the authors of
plperl will step up and fix it; I'm not sufficiently clear on what cases
they are trying to support to want to touch it.
 

I don't currently have the resources to clean this up properly. The 
attached patch tries to make clear in a comment what the code is doing, 
and also initializes these variables to NULL. If someone wants to take a 
stab at cleaning this up they are welcome to - I don't expect to be able 
to for quite a while.

The others indicate sloppiness in the C code generated by perl's XS
functionality.  There's nothing we can do about them.  FWIW, less
obsolete versions of Perl generate fewer warnings --- the only one of
these that I see on 5.8.0 and up is
 

SPI.c:158: warning: unused variable `items'
   

	
 

The patch also addresses this issue.
cheers
andrew
Index: SPI.xs
===
RCS file: /home/cvsmirror/pgsql/src/pl/plperl/SPI.xs,v
retrieving revision 1.10
diff -c -r1.10 SPI.xs
*** SPI.xs	20 Nov 2004 19:07:40 -	1.10
--- SPI.xs	21 Nov 2004 15:02:15 -
***
*** 94,96 
--- 94,100 
  		RETVAL = newRV_noinc((SV*) ret_hash);
  	OUTPUT:
  		RETVAL
+ 
+ 
+ BOOT:
+ items = 0;  /* avoid 'unused variable' warning */
Index: plperl.c
===
RCS file: /home/cvsmirror/pgsql/src/pl/plperl/plperl.c,v
retrieving revision 1.59
diff -c -r1.59 plperl.c
*** plperl.c	20 Nov 2004 19:07:40 -	1.59
--- plperl.c	21 Nov 2004 20:40:50 -
***
*** 963,971 
  
  	if (prodesc-fn_retistuple  fcinfo-resultinfo)	/* set of tuples */
  	{
  		/* SRF support */
! 		HV		   *ret_hv;
! 		AV		   *ret_av;
  		FuncCallContext *funcctx;
  		int			call_cntr;
  		int			max_calls;
--- 963,988 
  
  	if (prodesc-fn_retistuple  fcinfo-resultinfo)	/* set of tuples */
  	{
+ 
+ 		/*
+ 		 *  This branch will be taken when the function call
+ 		 *  appears on a context that can return a set of tuples
+ 		 *  even if it only actually returns a single tuple
+ 		 *  (e.g. select a from foo() where foor returns a singletone
+ 		 *  of some composite type with member a). In this case, the
+ 		 *  return value will be a hashref. If a rowset is returned
+ 		 *  it will be an arrayref whose members will be hashrefs.
+ 		 *
+ 		 *  Care is taken in the code only to refer to the appropriate
+ 		 *  one of ret_hv and ret_av, only one of which is therefore
+ 		 *  valid for any given call.
+ 		 *
+ 		 *  XXX This code is in dire need of cleanup.
+ 		 */
+ 	
  		/* SRF support */
! 		HV		   *ret_hv = NULL;
! 		AV		   *ret_av = NULL;
  		FuncCallContext *funcctx;
  		int			call_cntr;
  		int			max_calls;

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html


[PATCHES] pgcrypto: Makefile check

2004-11-21 Thread Neil Conway
This patch makes the pgcrypto Makefile check that a recognized random
source has been defined. If no such source is defined, pgcrypto will
compile successfully but will be unusable.

(An alternative place to do the check would be in random.c; comments on
which location is preferrable are welcome.)

Barring any objections I will apply this to HEAD later tonight.

-Neil

# 
# patch contrib/pgcrypto/Makefile
#  from [c549a19bc0a0ff6582bb02e37d2db011c1e0cf01]
#to [709404895862b1734a4c1af7ca0f9fb423097c0a]
# 
--- contrib/pgcrypto/Makefile
+++ contrib/pgcrypto/Makefile
@@ -48,13 +48,17 @@
 
 ifeq ($(random), dev)
 CRYPTO_CFLAGS += -DRAND_DEV=$(random_dev)
-endif
+else
 ifeq ($(random), openssl)
 CRYPTO_CFLAGS += -DRAND_OPENSSL
-endif
+else
 ifeq ($(random), silly)
 CRYPTO_CFLAGS += -DRAND_SILLY
+else
+$(error Unrecognized random source: $(random))
 endif
+endif
+endif
 
 SRCS		+= pgcrypto.c px.c px-hmac.c px-crypt.c misc.c \
 			crypt-gensalt.c random.c

---(end of broadcast)---
TIP 8: explain analyze is your friend


[PATCHES] release.sgml refers to g_restore

2004-11-21 Thread Michael Fuhr
The 8.0.0beta5 Release Notes contain a reference to g_restore instead
of pg_restore.

-- 
Michael Fuhr
http://www.fuhr.org/~mfuhr/
Index: doc/src/sgml/release.sgml
===
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/release.sgml,v
retrieving revision 1.311
diff -c -r1.311 release.sgml
*** doc/src/sgml/release.sgml   22 Nov 2004 00:37:59 -  1.311
--- doc/src/sgml/release.sgml   22 Nov 2004 05:43:01 -
***
*** 1862,1868 
  
  listitem
   para
!   Allow applicationg_restore/ to ignore some SQL errors (Fabien 
Coelho)
   /para
   para
This makes applicationpg_restore/'s behavior similar to the
--- 1862,1868 
  
  listitem
   para
!   Allow applicationpg_restore/ to ignore some SQL errors (Fabien 
Coelho)
   /para
   para
This makes applicationpg_restore/'s behavior similar to the

---(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] release.sgml refers to g_restore

2004-11-21 Thread Neil Conway
On Sun, 2004-11-21 at 22:49 -0700, Michael Fuhr wrote:
 The 8.0.0beta5 Release Notes contain a reference to g_restore instead
 of pg_restore.

Applied. Thanks!

-Neil



---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html


Re: [PATCHES] Archiver restart timer

2004-11-21 Thread Simon Riggs
On Sun, 2004-11-21 at 23:07, Simon Riggs wrote:
 I enclose a short patch to reduce the PGARCH_RESTART_INTERVAL from 60
 seconds to 10 seconds. The original number was plucked from thin air
 some months ago, and I'd like to review that now based upon further
 thought, observation and experience.
 
 This change has little or no effect on performance, since the interval
 is there mainly to avoid repeated respawn attempts if archiver fails at
 startup. Archiver start-up time is very quick, so there is little danger
 of exceeding 10 seconds.
 
 On a busy system, if the archiver does die, then many files can build up
 in the 60 seconds before respawning. That xlog file backlog could take
 some time to clear. This then leaves a larger than normal window of data
 loss for a possibly long period.
 
 It's a minor change only, with no other effect on function.

...and now for the diff -c version ;-)

-- 
Best Regards, Simon Riggs
Index: pgarch.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/postmaster/pgarch.c,v
retrieving revision 1.10
diff -d -c -r1.10 pgarch.c
*** pgarch.c	9 Nov 2004 13:01:26 -	1.10
--- pgarch.c	21 Nov 2004 22:59:03 -
***
*** 51,57 
  #define PGARCH_AUTOWAKE_INTERVAL 60		/* How often to force a poll of
  		 * the archive status directory;
  		 * in seconds. */
! #define PGARCH_RESTART_INTERVAL 60		/* How often to attempt to restart
  		 * a failed archiver; in seconds. */
  
  /* --
--- 51,57 
  #define PGARCH_AUTOWAKE_INTERVAL 60		/* How often to force a poll of
  		 * the archive status directory;
  		 * in seconds. */
! #define PGARCH_RESTART_INTERVAL 10		/* How often to attempt to restart
  		 * a failed archiver; in seconds. */
  
  /* --

---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match