Re: [PATCHES] [HACKERS] Upcoming back-branch update releases

Index: src/bin/psql/mbprint.c
===================================================================
RCS file: /cvsroot/pgsql/src/bin/psql/mbprint.c,v
retrieving revision 1.31
retrieving revision 1.32
diff -c -r1.31 -r1.32
*** src/bin/psql/mbprint.c 8 May 2008 17:04:26 -0000 1.31
--- src/bin/psql/mbprint.c 8 May 2008 19:11:36 -0000 1.32
***************
*** 3,9 ****
*
* Copyright (c) 2000-2008, PostgreSQL Global Development Group
*
! * $PostgreSQL: pgsql/src/bin/psql/mbprint.c,v 1.31 2008/05/08 17:04:26 momjian Exp $
*
* XXX this file does not really belong in psql/. Perhaps move to libpq?
* It also seems that the mbvalidate function is redundant with existing
--- 3,9 ----
*
* Copyright (c) 2000-2008, PostgreSQL Global Development Group
*
! * $PostgreSQL: pgsql/src/bin/psql/mbprint.c,v 1.32 2008/05/08 19:11:36 momjian Exp $
*
* XXX this file does not really belong in psql/. Perhaps move to libpq?
* It also seems that the mbvalidate function is redundant with existing
***************
*** 321,326 ****
--- 321,334 ----
linewidth += 2;
ptr += 2;
}
+ else if (*pwcs == '\t') /* Tab */
+ {
+ do
+ {
+ *ptr++ = ' ';
+ linewidth++;
+ } while (linewidth % 8 != 0);
+ }
else if (w < 0) /* Other control char */
{
sprintf((char *) ptr, "\\x%02X", *pwcs);
Index: src/test/regress/expected/prepare.out
===================================================================
RCS file: /cvsroot/pgsql/src/test/regress/expected/prepare.out,v
retrieving revision 1.15
retrieving revision 1.16
diff -c -r1.15 -r1.16
*** src/test/regress/expected/prepare.out 18 Jun 2007 21:40:58 -0000 1.15
--- src/test/regress/expected/prepare.out 8 May 2008 19:11:36 -0000 1.16
***************
*** 155,169 ****
name | statement | parameter_types
------+-----------------------------------------------------------------+--------------------------------------------------------
q2 | PREPARE q2(text) AS | {text}
! : \x09SELECT datname, datistemplate, datallowconn
! : \x09FROM pg_database WHERE datname = $1;
q3 | PREPARE q3(text, int, float, boolean, oid, smallint) AS | {text,integer,"double precision",boolean,oid,smallint}
! : \x09SELECT * FROM tenk1 WHERE string4 = $1 AND (four = $2 OR
! : \x09ten = $3::bigint OR true = $4 OR oid = $5 OR odd = $6::int)
! : \x09ORDER BY unique1;
q5 | PREPARE q5(int, text) AS | {integer,text}
! : \x09SELECT * FROM tenk1 WHERE unique1 = $1 OR stringu1 = $2
! : \x09ORDER BY unique1;
q6 | PREPARE q6 AS | {integer,name}
: SELECT * FROM tenk1 WHERE unique1 = $1 AND stringu1 = $2;
q7 | PREPARE q7(unknown) AS | {path}
--- 155,171 ----
name | statement | parameter_types
------+-----------------------------------------------------------------+--------------------------------------------------------
q2 | PREPARE q2(text) AS | {text}
! : SELECT datname, datistemplate, datallowconn
! : FROM pg_database WHERE datname = $1;
q3 | PREPARE q3(text, int, float, boolean, oid, smallint) AS | {text,integer,"double precision",boolean,oid,smallint}
! : SELECT * FROM tenk1 WHERE string4 = $1 AND (four = $2 O
! ; R
! : ten = $3::bigint OR true = $4 OR oid = $5 OR odd = $6::
! ; int)
! : ORDER BY unique1;
q5 | PREPARE q5(int, text) AS | {integer,text}
! : SELECT * FROM tenk1 WHERE unique1 = $1 OR stringu1 = $2
! : ORDER BY unique1;
q6 | PREPARE q6 AS | {integer,name}
: SELECT * FROM tenk1 WHERE unique1 = $1 AND stringu1 = $2;
q7 | PREPARE q7(unknown) AS | {path}
Index: src/bin/psql/mbprint.c
===================================================================
RCS file: /cvsroot/pgsql/src/bin/psql/mbprint.c,v
retrieving revision 1.32
retrieving revision 1.33
diff -c -r1.32 -r1.33
*** src/bin/psql/mbprint.c 8 May 2008 19:11:36 -0000 1.32
--- src/bin/psql/mbprint.c 9 May 2008 05:25:04 -0000 1.33
***************
*** 3,9 ****
*
* Copyright (c) 2000-2008, PostgreSQL Global Development Group
*
! * $PostgreSQL: pgsql/src/bin/psql/mbprint.c,v 1.32 2008/05/08 19:11:36 momjian Exp $
*
* XXX this file does not really belong in psql/. Perhaps move to libpq?
* It also seems that the mbvalidate function is redundant with existing
--- 3,9 ----
*
* Copyright (c) 2000-2008, PostgreSQL Global Development Group
*
! * $PostgreSQL: pgsql/src/bin/psql/mbprint.c,v 1.33 2008/05/09 05:25:04 tgl Exp $
*
* XXX this file does not really belong in psql/. Perhaps move to libpq?
* It also seems that the mbvalidate function is redundant with existing
***************
*** 205,216 ****
* pg_wcssize takes the given string in the given encoding and returns three
* values:
* result_width: Width in display characters of the longest line in string
! * result_height: Number of newlines in display output
! * result_format_size: Number of bytes required to store formatted representation of string
*/
! int
! pg_wcssize(unsigned char *pwcs, size_t len, int encoding, int *result_width,
! int *result_height, int *result_format_size)
{
int w,
chlen = 0,
--- 205,219 ----
* pg_wcssize takes the given string in the given encoding and returns three
* values:
* result_width: Width in display characters of the longest line in string
! * result_height: Number of lines in display output
! * result_format_size: Number of bytes required to store formatted
! * representation of string
! *
! * This MUST be kept in sync with pg_wcsformat!
*/
! void
! pg_wcssize(unsigned char *pwcs, size_t len, int encoding,
! int *result_width, int *result_height, int *result_format_size)
{
int w,
chlen = 0,
***************
*** 241,246 ****
--- 244,257 ----
linewidth += 2;
format_size += 2;
}
+ else if (*pwcs == '\t') /* Tab */
+ {
+ do
+ {
+ linewidth++;
+ format_size++;
+ } while (linewidth % 8 != 0);
+ }
else if (w < 0) /* Other control char */
{
linewidth += 4;
***************
*** 266,272 ****
}
if (linewidth > width)
width = linewidth;
! format_size += 1;

/* Set results */
if (result_width)
--- 277,283 ----
}
if (linewidth > width)
width = linewidth;
! format_size += 1; /* For NUL char */

/* Set results */
if (result_width)
***************
*** 275,288 ****
*result_height = height;
if (result_format_size)
*result_format_size = format_size;
-
- return width;
}

/*
! * Filter out unprintable characters, companion to wcs_size.
! * Break input into lines based on \n. lineptr[i].ptr == NULL
! * indicates the end of the array.
*/
void
pg_wcsformat(unsigned char *pwcs, size_t len, int encoding,
--- 286,298 ----
*result_height = height;
if (result_format_size)
*result_format_size = format_size;
}

/*
! * Format a string into one or more "struct lineptr" lines.
! * lines[i].ptr == NULL indicates the end of the array.
! *
! * This MUST be kept in sync with pg_wcssize!
*/
void
pg_wcsformat(unsigned char *pwcs, size_t len, int encoding,
***************
*** 309,315 ****
linewidth = 0;
lines++;
count--;
! if (count == 0)
exit(1); /* Screwup */

/* make next line point to remaining memory */
--- 319,325 ----
linewidth = 0;
lines++;
count--;
! if (count <= 0)
exit(1); /* Screwup */

/* make next line point to remaining memory */
***************
*** 346,359 ****
if (encoding == PG_UTF8)
sprintf((char *) ptr, "\\u%04X", utf2ucs(pwcs));
else
!
/*
* This case cannot happen in the current code because only
* UTF-8 signals multibyte control characters. But we may need
* to support it at some stage
*/
sprintf((char *) ptr, "\\u????");
!
ptr += 6;
linewidth += 6;
}
--- 356,369 ----
if (encoding == PG_UTF8)
sprintf((char *) ptr, "\\u%04X", utf2ucs(pwcs));
else
! {
/*
* This case cannot happen in the current code because only
* UTF-8 signals multibyte control characters. But we may need
* to support it at some stage
*/
sprintf((char *) ptr, "\\u????");
! }
ptr += 6;
linewidth += 6;
}
***************
*** 370,376 ****
lines->width = linewidth;
*ptr++ = '\0'; /* Terminate formatted string */

! if (count == 0)
exit(1); /* Screwup */

(lines+1)->ptr = NULL; /* terminate line array */
--- 380,386 ----
lines->width = linewidth;
*ptr++ = '\0'; /* Terminate formatted string */

! if (count <= 0)
exit(1); /* Screwup */

(lines+1)->ptr = NULL; /* terminate line array */
Index: src/bin/psql/mbprint.h
===================================================================
RCS file: /cvsroot/pgsql/src/bin/psql/mbprint.h,v
retrieving revision 1.11
retrieving revision 1.12
diff -c -r1.11 -r1.12
*** src/bin/psql/mbprint.h 4 Oct 2006 00:30:06 -0000 1.11
--- src/bin/psql/mbprint.h 9 May 2008 05:25:04 -0000 1.12
***************
*** 1,4 ****
! /* $PostgreSQL: pgsql/src/bin/psql/mbprint.h,v 1.11 2006/10/04 00:30:06 momjian Exp $ */
#ifndef MBPRINT_H
#define MBPRINT_H

--- 1,4 ----
! /* $PostgreSQL: pgsql/src/bin/psql/mbprint.h,v 1.12 2008/05/09 05:25:04 tgl Exp $ */
#ifndef MBPRINT_H
#define MBPRINT_H

***************
*** 13,18 ****

extern int pg_wcswidth(const unsigned char *pwcs, size_t len, int encoding);
extern void pg_wcsformat(unsigned char *pwcs, size_t len, int encoding, struct lineptr * lines, int count);
! extern int pg_wcssize(unsigned char *pwcs, size_t len, int encoding, int *width, int *height, int *format_size);

#endif /* MBPRINT_H */
--- 13,19 ----

extern int pg_wcswidth(const unsigned char *pwcs, size_t len, int encoding);
extern void pg_wcsformat(unsigned char *pwcs, size_t len, int encoding, struct lineptr * lines, int count);
! extern void pg_wcssize(unsigned char *pwcs, size_t len, int encoding,
! int *width, int *height, int *format_size);

#endif /* MBPRINT_H */
Index: src/test/regress/expected/prepare.out
===================================================================
RCS file: /cvsroot/pgsql/src/test/regress/expected/prepare.out,v
retrieving revision 1.16
retrieving revision 1.17
diff -c -r1.16 -r1.17
*** src/test/regress/expected/prepare.out 8 May 2008 19:11:36 -0000 1.16
--- src/test/regress/expected/prepare.out 9 May 2008 05:25:54 -0000 1.17
***************
*** 16,22 ****
SELECT name, statement, parameter_types FROM pg_prepared_statements;
name | statement | parameter_types
------+------------------------------+-----------------
! q1 | PREPARE q1 AS SELECT 1 AS a; | {}
(1 row)

-- should fail
--- 16,22 ----
SELECT name, statement, parameter_types FROM pg_prepared_statements;
name | statement | parameter_types
------+------------------------------+-----------------
! q1 | PREPARE q1 AS SELECT 1 AS a; | {}
(1 row)

-- should fail
***************
*** 35,42 ****
SELECT name, statement, parameter_types FROM pg_prepared_statements;
name | statement | parameter_types
------+------------------------------+-----------------
! q1 | PREPARE q1 AS SELECT 2; | {}
! q2 | PREPARE q2 AS SELECT 2 AS b; | {}
(2 rows)

-- sql92 syntax
--- 35,42 ----
SELECT name, statement, parameter_types FROM pg_prepared_statements;
name | statement | parameter_types
------+------------------------------+-----------------
! q1 | PREPARE q1 AS SELECT 2; | {}
! q2 | PREPARE q2 AS SELECT 2 AS b; | {}
(2 rows)

-- sql92 syntax
***************
*** 44,50 ****
SELECT name, statement, parameter_types FROM pg_prepared_statements;
name | statement | parameter_types
------+------------------------------+-----------------
! q2 | PREPARE q2 AS SELECT 2 AS b; | {}
(1 row)

DEALLOCATE PREPARE q2;
--- 44,50 ----
SELECT name, statement, parameter_types FROM pg_prepared_statements;
name | statement | parameter_types
------+------------------------------+-----------------
! q2 | PREPARE q2 AS SELECT 2 AS b; | {}
(1 row)

DEALLOCATE PREPARE q2;
***************
*** 61,67 ****
EXECUTE q2('regression');
datname | datistemplate | datallowconn
------------+---------------+--------------
! regression | f | t
(1 row)

PREPARE q3(text, int, float, boolean, oid, smallint) AS
--- 61,67 ----
EXECUTE q2('regression');
datname | datistemplate | datallowconn
------------+---------------+--------------
! regression | f | t
(1 row)

PREPARE q3(text, int, float, boolean, oid, smallint) AS
***************
*** 71,105 ****
EXECUTE q3('AAAAxx', 5::smallint, 10.5::float, false, 500::oid, 4::bigint);
unique1 | unique2 | two | four | ten | twenty | hundred | thousand | twothousand | fivethous | tenthous | odd | even | stringu1 | stringu2 | string4
---------+---------+-----+------+-----+--------+---------+----------+-------------+-----------+----------+-----+------+----------+----------+---------
! 2 | 2716 | 0 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 4 | 5 | CAAAAA | MAEAAA | AAAAxx
! 102 | 612 | 0 | 2 | 2 | 2 | 2 | 102 | 102 | 102 | 102 | 4 | 5 | YDAAAA | OXAAAA | AAAAxx
! 802 | 2908 | 0 | 2 | 2 | 2 | 2 | 802 | 802 | 802 | 802 | 4 | 5 | WEAAAA | WHEAAA | AAAAxx
! 902 | 1104 | 0 | 2 | 2 | 2 | 2 | 902 | 902 | 902 | 902 | 4 | 5 | SIAAAA | MQBAAA | AAAAxx
! 1002 | 2580 | 0 | 2 | 2 | 2 | 2 | 2 | 1002 | 1002 | 1002 | 4 | 5 | OMAAAA | GVDAAA | AAAAxx
! 1602 | 8148 | 0 | 2 | 2 | 2 | 2 | 602 | 1602 | 1602 | 1602 | 4 | 5 | QJAAAA | KBMAAA | AAAAxx
! 1702 | 7940 | 0 | 2 | 2 | 2 | 2 | 702 | 1702 | 1702 | 1702 | 4 | 5 | MNAAAA | KTLAAA | AAAAxx
! 2102 | 6184 | 0 | 2 | 2 | 2 | 2 | 102 | 102 | 2102 | 2102 | 4 | 5 | WCAAAA | WDJAAA | AAAAxx
! 2202 | 8028 | 0 | 2 | 2 | 2 | 2 | 202 | 202 | 2202 | 2202 | 4 | 5 | SGAAAA | UWLAAA | AAAAxx
! 2302 | 7112 | 0 | 2 | 2 | 2 | 2 | 302 | 302 | 2302 | 2302 | 4 | 5 | OKAAAA | ONKAAA | AAAAxx
! 2902 | 6816 | 0 | 2 | 2 | 2 | 2 | 902 | 902 | 2902 | 2902 | 4 | 5 | QHAAAA | ECKAAA | AAAAxx
! 3202 | 7128 | 0 | 2 | 2 | 2 | 2 | 202 | 1202 | 3202 | 3202 | 4 | 5 | ETAAAA | EOKAAA | AAAAxx
! 3902 | 9224 | 0 | 2 | 2 | 2 | 2 | 902 | 1902 | 3902 | 3902 | 4 | 5 | CUAAAA | UQNAAA | AAAAxx
! 4102 | 7676 | 0 | 2 | 2 | 2 | 2 | 102 | 102 | 4102 | 4102 | 4 | 5 | UBAAAA | GJLAAA | AAAAxx
! 4202 | 6628 | 0 | 2 | 2 | 2 | 2 | 202 | 202 | 4202 | 4202 | 4 | 5 | QFAAAA | YUJAAA | AAAAxx
! 4502 | 412 | 0 | 2 | 2 | 2 | 2 | 502 | 502 | 4502 | 4502 | 4 | 5 | ERAAAA | WPAAAA | AAAAxx
! 4702 | 2520 | 0 | 2 | 2 | 2 | 2 | 702 | 702 | 4702 | 4702 | 4 | 5 | WYAAAA | YSDAAA | AAAAxx
! 4902 | 1600 | 0 | 2 | 2 | 2 | 2 | 902 | 902 | 4902 | 4902 | 4 | 5 | OGAAAA | OJCAAA | AAAAxx
! 5602 | 8796 | 0 | 2 | 2 | 2 | 2 | 602 | 1602 | 602 | 5602 | 4 | 5 | MHAAAA | IANAAA | AAAAxx
! 6002 | 8932 | 0 | 2 | 2 | 2 | 2 | 2 | 2 | 1002 | 6002 | 4 | 5 | WWAAAA | OFNAAA | AAAAxx
! 6402 | 3808 | 0 | 2 | 2 | 2 | 2 | 402 | 402 | 1402 | 6402 | 4 | 5 | GMAAAA | MQFAAA | AAAAxx
! 7602 | 1040 | 0 | 2 | 2 | 2 | 2 | 602 | 1602 | 2602 | 7602 | 4 | 5 | KGAAAA | AOBAAA | AAAAxx
! 7802 | 7508 | 0 | 2 | 2 | 2 | 2 | 802 | 1802 | 2802 | 7802 | 4 | 5 | COAAAA | UCLAAA | AAAAxx
! 8002 | 9980 | 0 | 2 | 2 | 2 | 2 | 2 | 2 | 3002 | 8002 | 4 | 5 | UVAAAA | WTOAAA | AAAAxx
! 8302 | 7800 | 0 | 2 | 2 | 2 | 2 | 302 | 302 | 3302 | 8302 | 4 | 5 | IHAAAA | AOLAAA | AAAAxx
! 8402 | 5708 | 0 | 2 | 2 | 2 | 2 | 402 | 402 | 3402 | 8402 | 4 | 5 | ELAAAA | OLIAAA | AAAAxx
! 8602 | 5440 | 0 | 2 | 2 | 2 | 2 | 602 | 602 | 3602 | 8602 | 4 | 5 | WSAAAA | GBIAAA | AAAAxx
! 9502 | 1812 | 0 | 2 | 2 | 2 | 2 | 502 | 1502 | 4502 | 9502 | 4 | 5 | MBAAAA | SRCAAA | AAAAxx
! 9602 | 9972 | 0 | 2 | 2 | 2 | 2 | 602 | 1602 | 4602 | 9602 | 4 | 5 | IFAAAA | OTOAAA | AAAAxx
(29 rows)

-- too few params
--- 71,105 ----
EXECUTE q3('AAAAxx', 5::smallint, 10.5::float, false, 500::oid, 4::bigint);
unique1 | unique2 | two | four | ten | twenty | hundred | thousand | twothousand | fivethous | tenthous | odd | even | stringu1 | stringu2 | string4
---------+---------+-----+------+-----+--------+---------+----------+-------------+-----------+----------+-----+------+----------+----------+---------
! 2 | 2716 | 0 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 4 | 5 | CAAAAA | MAEAAA | AAAAxx
! 102 | 612 | 0 | 2 | 2 | 2 | 2 | 102 | 102 | 102 | 102 | 4 | 5 | YDAAAA | OXAAAA | AAAAxx
! 802 | 2908 | 0 | 2 | 2 | 2 | 2 | 802 | 802 | 802 | 802 | 4 | 5 | WEAAAA | WHEAAA | AAAAxx
! 902 | 1104 | 0 | 2 | 2 | 2 | 2 | 902 | 902 | 902 | 902 | 4 | 5 | SIAAAA | MQBAAA | AAAAxx
! 1002 | 2580 | 0 | 2 | 2 | 2 | 2 | 2 | 1002 | 1002 | 1002 | 4 | 5 | OMAAAA | GVDAAA | AAAAxx
! 1602 | 8148 | 0 | 2 | 2 | 2 | 2 | 602 | 1602 | 1602 | 1602 | 4 | 5 | QJAAAA | KBMAAA | AAAAxx
! 1702 | 7940 | 0 | 2 | 2 | 2 | 2 | 702 | 1702 | 1702 | 1702 | 4 | 5 | MNAAAA | KTLAAA | AAAAxx
! 2102 | 6184 | 0 | 2 | 2 | 2 | 2 | 102 | 102 | 2102 | 2102 | 4 | 5 | WCAAAA | WDJAAA | AAAAxx
! 2202 | 8028 | 0 | 2 | 2 | 2 | 2 | 202 | 202 | 2202 | 2202 | 4 | 5 | SGAAAA | UWLAAA | AAAAxx
! 2302 | 7112 | 0 | 2 | 2 | 2 | 2 | 302 | 302 | 2302 | 2302 | 4 | 5 | OKAAAA | ONKAAA | AAAAxx
! 2902 | 6816 | 0 | 2 | 2 | 2 | 2 | 902 | 902 | 2902 | 2902 | 4 | 5 | QHAAAA | ECKAAA | AAAAxx
! 3202 | 7128 | 0 | 2 | 2 | 2 | 2 | 202 | 1202 | 3202 | 3202 | 4 | 5 | ETAAAA | EOKAAA | AAAAxx
! 3902 | 9224 | 0 | 2 | 2 | 2 | 2 | 902 | 1902 | 3902 | 3902 | 4 | 5 | CUAAAA | UQNAAA | AAAAxx
! 4102 | 7676 | 0 | 2 | 2 | 2 | 2 | 102 | 102 | 4102 | 4102 | 4 | 5 | UBAAAA | GJLAAA | AAAAxx
! 4202 | 6628 | 0 | 2 | 2 | 2 | 2 | 202 | 202 | 4202 | 4202 | 4 | 5 | QFAAAA | YUJAAA | AAAAxx
! 4502 | 412 | 0 | 2 | 2 | 2 | 2 | 502 | 502 | 4502 | 4502 | 4 | 5 | ERAAAA | WPAAAA | AAAAxx
! 4702 | 2520 | 0 | 2 | 2 | 2 | 2 | 702 | 702 | 4702 | 4702 | 4 | 5 | WYAAAA | YSDAAA | AAAAxx
! 4902 | 1600 | 0 | 2 | 2 | 2 | 2 | 902 | 902 | 4902 | 4902 | 4 | 5 | OGAAAA | OJCAAA | AAAAxx
! 5602 | 8796 | 0 | 2 | 2 | 2 | 2 | 602 | 1602 | 602 | 5602 | 4 | 5 | MHAAAA | IANAAA | AAAAxx
! 6002 | 8932 | 0 | 2 | 2 | 2 | 2 | 2 | 2 | 1002 | 6002 | 4 | 5 | WWAAAA | OFNAAA | AAAAxx
! 6402 | 3808 | 0 | 2 | 2 | 2 | 2 | 402 | 402 | 1402 | 6402 | 4 | 5 | GMAAAA | MQFAAA | AAAAxx
! 7602 | 1040 | 0 | 2 | 2 | 2 | 2 | 602 | 1602 | 2602 | 7602 | 4 | 5 | KGAAAA | AOBAAA | AAAAxx
! 7802 | 7508 | 0 | 2 | 2 | 2 | 2 | 802 | 1802 | 2802 | 7802 | 4 | 5 | COAAAA | UCLAAA | AAAAxx
! 8002 | 9980 | 0 | 2 | 2 | 2 | 2 | 2 | 2 | 3002 | 8002 | 4 | 5 | UVAAAA | WTOAAA | AAAAxx
! 8302 | 7800 | 0 | 2 | 2 | 2 | 2 | 302 | 302 | 3302 | 8302 | 4 | 5 | IHAAAA | AOLAAA | AAAAxx
! 8402 | 5708 | 0 | 2 | 2 | 2 | 2 | 402 | 402 | 3402 | 8402 | 4 | 5 | ELAAAA | OLIAAA | AAAAxx
! 8602 | 5440 | 0 | 2 | 2 | 2 | 2 | 602 | 602 | 3602 | 8602 | 4 | 5 | WSAAAA | GBIAAA | AAAAxx
! 9502 | 1812 | 0 | 2 | 2 | 2 | 2 | 502 | 1502 | 4502 | 9502 | 4 | 5 | MBAAAA | SRCAAA | AAAAxx
! 9602 | 9972 | 0 | 2 | 2 | 2 | 2 | 602 | 1602 | 4602 | 9602 | 4 | 5 | IFAAAA | OTOAAA | AAAAxx
(29 rows)

-- too few params
***************
*** 127,148 ****
SELECT * FROM q5_prep_results;
unique1 | unique2 | two | four | ten | twenty | hundred | thousand | twothousand | fivethous | tenthous | odd | even | stringu1 | stringu2 | string4
---------+---------+-----+------+-----+--------+---------+----------+-------------+-----------+----------+-----+------+----------+----------+---------
! 200 | 9441 | 0 | 0 | 0 | 0 | 0 | 200 | 200 | 200 | 200 | 0 | 1 | SHAAAA | DZNAAA | HHHHxx
! 497 | 9092 | 1 | 1 | 7 | 17 | 97 | 497 | 497 | 497 | 497 | 194 | 195 | DTAAAA | SLNAAA | AAAAxx
! 1173 | 6699 | 1 | 1 | 3 | 13 | 73 | 173 | 1173 | 1173 | 1173 | 146 | 147 | DTAAAA | RXJAAA | VVVVxx
! 1849 | 8143 | 1 | 1 | 9 | 9 | 49 | 849 | 1849 | 1849 | 1849 | 98 | 99 | DTAAAA | FBMAAA | VVVVxx
! 2525 | 64 | 1 | 1 | 5 | 5 | 25 | 525 | 525 | 2525 | 2525 | 50 | 51 | DTAAAA | MCAAAA | AAAAxx
! 3201 | 7309 | 1 | 1 | 1 | 1 | 1 | 201 | 1201 | 3201 | 3201 | 2 | 3 | DTAAAA | DVKAAA | HHHHxx
! 3877 | 4060 | 1 | 1 | 7 | 17 | 77 | 877 | 1877 | 3877 | 3877 | 154 | 155 | DTAAAA | EAGAAA | AAAAxx
! 4553 | 4113 | 1 | 1 | 3 | 13 | 53 | 553 | 553 | 4553 | 4553 | 106 | 107 | DTAAAA | FCGAAA | HHHHxx
! 5229 | 6407 | 1 | 1 | 9 | 9 | 29 | 229 | 1229 | 229 | 5229 | 58 | 59 | DTAAAA | LMJAAA | VVVVxx
! 5905 | 9537 | 1 | 1 | 5 | 5 | 5 | 905 | 1905 | 905 | 5905 | 10 | 11 | DTAAAA | VCOAAA | HHHHxx
! 6581 | 4686 | 1 | 1 | 1 | 1 | 81 | 581 | 581 | 1581 | 6581 | 162 | 163 | DTAAAA | GYGAAA | OOOOxx
! 7257 | 1895 | 1 | 1 | 7 | 17 | 57 | 257 | 1257 | 2257 | 7257 | 114 | 115 | DTAAAA | XUCAAA | VVVVxx
! 7933 | 4514 | 1 | 1 | 3 | 13 | 33 | 933 | 1933 | 2933 | 7933 | 66 | 67 | DTAAAA | QRGAAA | OOOOxx
! 8609 | 5918 | 1 | 1 | 9 | 9 | 9 | 609 | 609 | 3609 | 8609 | 18 | 19 | DTAAAA | QTIAAA | OOOOxx
! 9285 | 8469 | 1 | 1 | 5 | 5 | 85 | 285 | 1285 | 4285 | 9285 | 170 | 171 | DTAAAA | TNMAAA | HHHHxx
! 9961 | 2058 | 1 | 1 | 1 | 1 | 61 | 961 | 1961 | 4961 | 9961 | 122 | 123 | DTAAAA | EBDAAA | OOOOxx
(16 rows)

-- unknown or unspecified parameter types: should succeed
--- 127,148 ----
SELECT * FROM q5_prep_results;
unique1 | unique2 | two | four | ten | twenty | hundred | thousand | twothousand | fivethous | tenthous | odd | even | stringu1 | stringu2 | string4
---------+---------+-----+------+-----+--------+---------+----------+-------------+-----------+----------+-----+------+----------+----------+---------
! 200 | 9441 | 0 | 0 | 0 | 0 | 0 | 200 | 200 | 200 | 200 | 0 | 1 | SHAAAA | DZNAAA | HHHHxx
! 497 | 9092 | 1 | 1 | 7 | 17 | 97 | 497 | 497 | 497 | 497 | 194 | 195 | DTAAAA | SLNAAA | AAAAxx
! 1173 | 6699 | 1 | 1 | 3 | 13 | 73 | 173 | 1173 | 1173 | 1173 | 146 | 147 | DTAAAA | RXJAAA | VVVVxx
! 1849 | 8143 | 1 | 1 | 9 | 9 | 49 | 849 | 1849 | 1849 | 1849 | 98 | 99 | DTAAAA | FBMAAA | VVVVxx
! 2525 | 64 | 1 | 1 | 5 | 5 | 25 | 525 | 525 | 2525 | 2525 | 50 | 51 | DTAAAA | MCAAAA | AAAAxx
! 3201 | 7309 | 1 | 1 | 1 | 1 | 1 | 201 | 1201 | 3201 | 3201 | 2 | 3 | DTAAAA | DVKAAA | HHHHxx
! 3877 | 4060 | 1 | 1 | 7 | 17 | 77 | 877 | 1877 | 3877 | 3877 | 154 | 155 | DTAAAA | EAGAAA | AAAAxx
! 4553 | 4113 | 1 | 1 | 3 | 13 | 53 | 553 | 553 | 4553 | 4553 | 106 | 107 | DTAAAA | FCGAAA | HHHHxx
! 5229 | 6407 | 1 | 1 | 9 | 9 | 29 | 229 | 1229 | 229 | 5229 | 58 | 59 | DTAAAA | LMJAAA | VVVVxx
! 5905 | 9537 | 1 | 1 | 5 | 5 | 5 | 905 | 1905 | 905 | 5905 | 10 | 11 | DTAAAA | VCOAAA | HHHHxx
! 6581 | 4686 | 1 | 1 | 1 | 1 | 81 | 581 | 581 | 1581 | 6581 | 162 | 163 | DTAAAA | GYGAAA | OOOOxx
! 7257 | 1895 | 1 | 1 | 7 | 17 | 57 | 257 | 1257 | 2257 | 7257 | 114 | 115 | DTAAAA | XUCAAA | VVVVxx
! 7933 | 4514 | 1 | 1 | 3 | 13 | 33 | 933 | 1933 | 2933 | 7933 | 66 | 67 | DTAAAA | QRGAAA | OOOOxx
! 8609 | 5918 | 1 | 1 | 9 | 9 | 9 | 609 | 609 | 3609 | 8609 | 18 | 19 | DTAAAA | QTIAAA | OOOOxx
! 9285 | 8469 | 1 | 1 | 5 | 5 | 85 | 285 | 1285 | 4285 | 9285 | 170 | 171 | DTAAAA | TNMAAA | HHHHxx
! 9961 | 2058 | 1 | 1 | 1 | 1 | 61 | 961 | 1961 | 4961 | 9961 | 122 | 123 | DTAAAA | EBDAAA | OOOOxx
(16 rows)

-- unknown or unspecified parameter types: should succeed
***************
*** 152,175 ****
SELECT * FROM road WHERE thepath = $1;
SELECT name, statement, parameter_types FROM pg_prepared_statements
ORDER BY name;
! name | statement | parameter_types
! ------+-----------------------------------------------------------------+--------------------------------------------------------
! q2 | PREPARE q2(text) AS | {text}
! : SELECT datname, datistemplate, datallowconn
! : FROM pg_database WHERE datname = $1;
! q3 | PREPARE q3(text, int, float, boolean, oid, smallint) AS | {text,integer,"double precision",boolean,oid,smallint}
! : SELECT * FROM tenk1 WHERE string4 = $1 AND (four = $2 O
! ; R
! : ten = $3::bigint OR true = $4 OR oid = $5 OR odd = $6::
! ; int)
! : ORDER BY unique1;
! q5 | PREPARE q5(int, text) AS | {integer,text}
! : SELECT * FROM tenk1 WHERE unique1 = $1 OR stringu1 = $2
! : ORDER BY unique1;
! q6 | PREPARE q6 AS | {integer,name}
! : SELECT * FROM tenk1 WHERE unique1 = $1 AND stringu1 = $2;
! q7 | PREPARE q7(unknown) AS | {path}
! : SELECT * FROM road WHERE thepath = $1;
(5 rows)

-- test DEALLOCATE ALL;
--- 152,173 ----
SELECT * FROM road WHERE thepath = $1;
SELECT name, statement, parameter_types FROM pg_prepared_statements
ORDER BY name;
! name | statement | parameter_types
! ------+---------------------------------------------------------------------+--------------------------------------------------------
! q2 | PREPARE q2(text) AS | {text}
! : SELECT datname, datistemplate, datallowconn
! : FROM pg_database WHERE datname = $1;
! q3 | PREPARE q3(text, int, float, boolean, oid, smallint) AS | {text,integer,"double precision",boolean,oid,smallint}
! : SELECT * FROM tenk1 WHERE string4 = $1 AND (four = $2 OR
! : ten = $3::bigint OR true = $4 OR oid = $5 OR odd = $6::int)
! : ORDER BY unique1;
! q5 | PREPARE q5(int, text) AS | {integer,text}
! : SELECT * FROM tenk1 WHERE unique1 = $1 OR stringu1 = $2
! : ORDER BY unique1;
! q6 | PREPARE q6 AS | {integer,name}
! : SELECT * FROM tenk1 WHERE unique1 = $1 AND stringu1 = $2;
! q7 | PREPARE q7(unknown) AS | {path}
! : SELECT * FROM road WHERE thepath = $1;
(5 rows)

-- test DEALLOCATE ALL;
Guillaume Smet wrote:
> On Wed, May 28, 2008 at 4:10 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > If you've got any bug fixes you've been working on, now is a good time
> > to get them finished up and sent in...
>
> Has the s/\x09/ /g patch for psql from Bruce and you been
> backported to 8.3? I didn't see it on pgsql-commiters.

No. I have not backpatched it because Tom found a problem with my
applied patch and did a second patch.

I am attaching both patches. The second one is Tom's and I don't
understand it well enough to backpatch it.

--
Bruce Momjian <bruce@momjian.us>

http://momjian.us

EnterpriseDB

http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Re: [pgsql-www] replace training blurb with upcoming pug meetings?

On Thu, May 29, 2008 at 7:35 AM, Dave Page <dpage@pgadmin.org> wrote:
> On Thu, May 29, 2008 at 3:31 PM, Selena Deckelmann
> <selenamarie@gmail.com> wrote:
>
>> I think UKPUG is
>> the only group ambitious enough to suggest a weekly pub night, but I
>> would love to be proved wrong.
>
> Weekly is not strictly accurate - that's just Greg and I trying to
> escape from the office on a Friday :-p. We were thinking of every few
> months.

To be honest, I think that's the best reason to have a meeting "about"
PostgreSQL I've heard. ;)

Some other group, then, will need to take up the Weekly Pub Challenge.
Sweden, perhaps?

-selena

--
Selena Deckelmann
United States PostgreSQL Association - http://www.postgresql.us
PDXPUG - http://pugs.postgresql.org/pdx
Me - http://www.chesnok.com/daily

--
Sent via pgsql-www mailing list (pgsql-www@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www

Re: [pgsql-www] replace training blurb with upcoming pug meetings?

On Thu, May 29, 2008 at 3:31 PM, Selena Deckelmann
<selenamarie@gmail.com> wrote:

> I think UKPUG is
> the only group ambitious enough to suggest a weekly pub night, but I
> would love to be proved wrong.

Weekly is not strictly accurate - that's just Greg and I trying to
escape from the office on a Friday :-p. We were thinking of every few
months.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

--
Sent via pgsql-www mailing list (pgsql-www@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www

Re: [GENERAL] New MS patent: sounds like PG db rules

Nikola Milutinovic wrote:

Still, this sounds dangerous. It should be, even legally, WRONG to patent something that already exist and was not invented by the patentee. I know we can laugh off MS in court, but what about new DBs or project even built on PG that have this functionality? Software patents are a menace, I'm afraid. And this is still just one portion. IBM is also into this line of "work".

Nix.

----- Original Message ----
From: Dave Page <dpage@pgadmin.org>
To: Justin Clift <justin@salasaga.org>
Cc: Jonathan Bond-Caron <jbondc@gmail.com>; A. Kretschmer <andreas.kretschmer@schollglas.com>; pgsql-general@postgresql.org
Sent: Tuesday, May 27, 2008 3:18:31 PM
Subject: Re: [GENERAL] New MS patent: sounds like PG db rules

HI Justin

On Tue, May 27, 2008 at 2:06 PM, Justin Clift <justin@salasaga.org> wrote:

> I'm trying to point out that - PG is a database system - and MS may have
> just been granted a patent for a fundamental part of it.
>
> Thinking it might need looking in to, and trying to bring it to the
> attention of some that can (or even cares?). ;>

I don't think it's a major issue. Even if MS do think we infringe on
the patent it would be laughable for them to try to do anything about
it given that our rules implementation has provably existed in a
leading FOSS project for a decade or more.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Question???  Does the license that Postgresql works under allow for a foundation or non for profit entity be created  that would hold onto patents for original  ideas of the contributors so WE can protect the users and developers of postgresql

The idea start playing the game MS and other Software companies are playing where they keep applying for  patents/copyrights where there is prior art.  This would protect everyone  in the development chain from having defend stupid lawsuits that these companies could bring against the biggest offenders.

USPTO  only looks at existing patents and trademarks to see if they can issue a patent .  So if a patent  makes claims on already existing art it puts the burden on the original inventor to get the patent revoke.  Doing the above would help put an end to this.

This is just a suggestion.

Re: [HACKERS] [PERFORM] Memory question on win32 systems

On Thu, May 29, 2008 at 10:19 AM, Justin <justin@emproshunts.com> wrote:
> To my understanding Postgresql only caches queries and results in memory for
> that specific connection. So when that connection is closed those cached
> results are cleared out. So cached indexs and queries are for that
> connection only. I hope my understanding is correct.

completely wrong.

They are called 'shared' buffers for a reason. Also you are missing
the point of the o/s file cache which lies under that. If you have a
computer with 4gb ram that is addressable, all its memory is used for
caching at all times, period, less what operating system needs or what
is used by running programs or temporary demands (sorting, etc).

Also, postgresql doesn't as a rule cache 'results and queries'.

shared buffers setting reserves memory for postgresql's internal cache
(plus some housekeeping things like locks)...which can be faster than
the o/s cache because it is more tightly integrated with the backend.
However a page fault to disk is much more interesting in performance
terms than the performance differences between shared buffers and o/s
cache.

merlin

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [pgsql-www] replace training blurb with upcoming pug meetings?

Hi Peter,

I imagine you're fully recovered from your race at this point! :)
Nice to meet you at PgCon.

On Thu, May 29, 2008 at 3:14 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
> Robert Treat wrote:
>> In an effort to give more visibility to the pugs, one idea that was floated
>> around was replacing the training blurb on the main site with an "upcoming
>> pugs" section, modeled after the upcoming events.
>
> I think this would probably be a very skewed listing. Some user groups never
> have real meetings, at least not outside of yearly events that are listed
> anyway. Others might meet weekly for pub night. There would need to be a
> fair amount of researching and policy making before such a listing could be
> produced in a fair manner.

The policy is simple: list events from groups that are having upcoming
meetings. PgDays and conferences should still be listed under Events,
rather than under PUGs.

The primary goal in presenting PUGs on the front page is to show to
outsiders how much growth there has been in user group activity. It's
an indicator that "people like me" use PostgreSQL. Listing these on
the front page is also a not-so-subtle encouragement to PUGs that we'd
like more regular meetings.

Here's a rough indication of events:

There are five groups in the US that are having monthly meetings. Last
I heard, the Moscow group was meeting monthly. Several groups have
just had their first meeting in the last two months. I think UKPUG is
the only group ambitious enough to suggest a weekly pub night, but I
would love to be proved wrong. The other groups, I will contact and
find out how frequently they meet.

-selena

--
Selena Deckelmann
United States PostgreSQL Association - http://www.postgresql.us
PDXPUG - http://pugs.postgresql.org/pdx
Me - http://www.chesnok.com/daily

--
Sent via pgsql-www mailing list (pgsql-www@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www

Re: [HACKERS] [PERFORM] Memory question on win32 systems

On Thu, May 29, 2008 at 10:19:46AM -0400, Justin wrote:
> To my understanding Postgresql only caches queries and results in memory
> for that specific connection. So when that connection is closed those
> cached results are cleared out. So cached indexs and queries are for
> that connection only. I hope my understanding is correct.

Incorrect, the shared buffer cache is shared between all running
postgresql processes and between connections. Also the OS cache is
shared between all programs on the system.

Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org>

http://svana.org/kleptog/
> Please line up in a tree and maintain the heap invariant while
> boarding. Thank you for flying nlogn airlines.

Re: [BUGS] BUG #4186: set lc_messages does not work

Magnus Hagander <magnus@hagander.net> writes:
> Thomas H. wrote:
>> so at least that explains the "changed" behaviour. nevertheless,
>> LC_MESSAGES seems to be defunct - with the "locale" folder present,
>> pg always picks the os' language and ignores the lc_message value.

> This looks like I can reproduce though, at least on cvs head. Did this
> work for you in previous versions?

Maybe we were using a different build of gettext in the previous
releases, one that didn't look at the same info as the current code?

Anyway the patch mentioned at the start of the thread
http://archives.postgresql.org/pgsql-patches/2008-02/msg00038.php
purports to fix this. It doesn't seem to have gotten reviewed
though.

regards, tom lane

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

[BUGS] BUG #4208: Server crashes on insert into gist index

The following bug has been logged online:

Bug reference: 4208
Logged by: Ron Mackley
Email address: ronm@signalpatterns.com
PostgreSQL version: 8.2.6
Operating system: Linux {hostname removed} 2.6.18-53.1.13.el5 #1 SMP Mon
Feb 11 13:27:27 EST 2008 x86_64 x86_64 x86_64 GNU/Linux
Description: Server crashes on insert into gist index
Details:

We've been seeing infrequent crashes of the postgres. This is version 8.2.6
running on Red Hat Enterprise 5.1 on x64 using redhat issued RPMs.

We captured a core file and here is the stack trace:

(gdb) bt
#0 0x0000000000615b5a in pfree (pointer=0x2aaaccaff318) at mcxt.c:585
#1 0x00002aaace72ab59 in cube_inter (fcinfo=0x7fff102205f0) at cube.c:898
#2 0x0000000000602b14 in DirectFunctionCall2 (func=0x2aaace72aa00
<cube_inter>, arg1=46913066890008, arg2=5) at fmgr.c:888
#3 0x00002aaace72a73b in g_cube_picksplit (fcinfo=<value optimized out>) at
cube.c:571
#4 0x000000000060224f in FunctionCall2 (flinfo=0x2aaaccaff318,
arg1=46913066890008, arg2=5) at fmgr.c:1162
#5 0x000000000044d6e6 in gistSplitByKey (r=0x2aaace6b6d40,
page=0x2aaaccafe8a0 "\017", itup=0x3628200, len=83,
giststate=0x7fff10221800, v=0x7fff10221420,
entryvec=0x36269e0, attno=0) at gistsplit.c:306
#6 0x0000000000444b15 in gistSplit (r=0x2aaace6b6d40, page=0x2aaaccafe8a0
"\017", itup=0x3628200, len=83, giststate=0x7fff10221800) at gist.c:943
#7 0x00000000004454ff in gistmakedeal (state=0x7fff10221780,
giststate=0x7fff10221800) at gist.c:329
#8 0x0000000000445d4b in gistdoinsert (r=0x2aaace6b6d40, itup=0x362aa90,
freespace=0, giststate=0x7fff10221800) at gist.c:278
#9 0x0000000000446115 in gistinsert (fcinfo=<value optimized out>) at
gist.c:242
#10 0x0000000000601eec in FunctionCall6 (flinfo=0x75000,
arg1=46913066890008, arg2=5, arg3=5, arg4=0, arg5=4, arg6=0) at fmgr.c:1275
#11 0x000000000045a03f in index_insert (indexRelation=0x2aaace6b6d40,
values=0x7fff10223f90, isnull=0x7fff10224090 "", heap_t_ctid=0x360256c,
heapRelation=0x2aaace6af020, check_uniqueness=0 '\0') at indexam.c:196
#12 0x00000000005082bf in ExecInsertIndexTuples (slot=0x36011b8,
tupleid=0x360256c, estate=0x3600d10, is_vacuum=0 '\0') at execUtils.c:1116
#13 0x00000000005006f1 in ExecutorRun (queryDesc=<value optimized out>,
direction=<value optimized out>, count=0) at execMain.c:1401
#14 0x00000000005880d7 in ProcessQuery (parsetree=<value optimized out>,
plan=0x35b2ff8, params=0x0, dest=0x35b36d0, completionTag=0x7fff10224440 "")
at pquery.c:157
#15 0x0000000000588311 in PortalRunMulti (portal=0x35f63e0, dest=0x35b36d0,
altdest=0x35b36d0, completionTag=0x7fff10224440 "") at pquery.c:1150
#16 0x0000000000588b74 in PortalRun (portal=0x35f63e0,
count=9223372036854775807, dest=0x35b36d0, altdest=0x35b36d0,
completionTag=0x7fff10224440 "") at pquery.c:700
#17 0x0000000000584a9f in exec_simple_query (
query_string=0x35b2650 "INSERT INTO user_attribute_vectors
(\"client_id\", \"survey_id\", \"user_id\", \"attribute_vector\") VALUES(1,
1, 9180,
E'(0.924332429795696,0.568812924744321,0.568812924744321,-0.599309532325997,
-1.462648746"...) at postgres.c:939
#18 0x0000000000585f22 in PostgresMain (argc=4, argv=<value optimized out>,
username=0x35396f0 "signalmatch-production") at postgres.c:3424
#19 0x000000000055f1c7 in ServerLoop () at postmaster.c:2934
#20 0x000000000055fdda in PostmasterMain (argc=5, argv=0x3519bb0) at
postmaster.c:966
#21 0x00000000005208e3 in main (argc=5, argv=<value optimized out>) at
main.c:188
(gdb)

And more information about the table:
sp_hub_production=# select count(*) from user_attribute_vectors;
count
-------
6057
(1 row)

sp_hub_production=# \d user_attribute_vectors
Table "public.user_attribute_vectors"
Column | Type | Modifiers

------------------+---------+-----------------------------------------------
----------------------
id | integer | not null default
nextval('user_attribute_vectors_id_seq'::regclass)
user_id | integer |
client_id | integer |
survey_id | integer |
attribute_vector | cube |
Indexes:
"user_attribute_vectors_pkey" PRIMARY KEY, btree (id)
"index_user_attribute_vectors_on_attribute_vector_gist" gist
(attribute_vector)
"index_user_attribute_vectors_on_user_id" btree (user_id)

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [HACKERS] [PERFORM] Memory question on win32 systems

Sabbiolina wrote:

On Thu, May 29, 2008 at 2:11 AM, Douglas McNaught <doug@mcnaught.org> wrote:

On Wed, May 28, 2008 at 7:05 PM, Sabbiolina <sabbiolina@gmail.com> wrote:
> Hello, in my particular case I need to configure Postgres to handle only a
> few concurrent connections, but I need it to be blazingly fast, so I need it
> to cache everything possible. I've changed the config file and multiplied
> all memory-related values by 10, still Postgres uses only less than 50 Mb of
> my RAM.

How are you measuring this?

Task Manager

> I have 4 Gigs of RAM, how do I force Postgres to use a higher part of such
> memory in order to cache more indexes, queries and so on?

Post the settings values you're using and people will be better able
to help you.

-Doug

config:
port = 5432                # (change requires restart)
max_connections = 50                    # (change requires restart)

shared_buffers = 320MB            # min 128kB or max_connections*16kB
temp_buffers = 80MB            # min 800kB
max_prepared_transactions = 10        # can be 0 or more
work_mem = 10MB                # min 64kB
maintenance_work_mem = 160MB        # min 1MB
Max_stack_depth = 20MB            # min 100kB
max_fsm_pages = 2048000            # min max_fsm_relations*16, 6 bytes each
max_fsm_relations = 10000        # min 100, ~70 bytes each
shared_preload_libraries = '$libdir/plugins/plugin

_debugger.dll'        # (change requires restart)
wal_buffers = 640kB            # min 32kB

log_destination = 'stderr'        # Valid values are combinations of
logging_collector = on        # Enable capturing of stderr and csvlog
log_line_prefix = '%t '            # special values:

datestyle = 'iso, dmy'
lc_messages = 'Italian_Italy.1252'            # locale for system error message
lc_monetary = 'Italian_Italy.1252'            # locale for monetary formatting
lc_numeric = 'Italian_Italy.1252'            # locale for number formatting
lc_time = 'Italian_Italy.1252'                # locale for time formatting
default_text_search_config = 'pg_catalog.italian'

Need to Use Performance monitor and Process Explorer to track down the caching on windows machines and performance.

Postgresql does not work like MS SQL where when it start ups grabs a large chuck memory that it uses to keep  last  X number of queries along with the indexes and tables in memory then its pushed out only when new queries that completely different need the memory.

To my understanding Postgresql only caches queries and results in memory for that specific connection.  So when that connection is closed those cached results are cleared out.    So cached indexs and queries are for that connection only.   I hope my understanding is correct.

Re: [pgsql-es-ayuda] PostgreSQL en Chile, jornadas

Guido Barosio escribió:
> Desconozco, sinceramente me llego la nota y la comparti con el grupo.
>
> Quizas Alvaro o alguno de los chicos de Chile nos pueda dar una idea

La verdad es que no había oído hablar de este evento, ni tengo idea
quién daba la charla de Slony.

¿Quizás alguien nos puede contar cómo estuvo?

--
Alvaro Herrera

http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
--
TIP 2: puedes desuscribirte de todas las listas simultáneamente
(envía "unregister TuDirecciónDeCorreo" a majordomo@postgresql.org)

Re: [HACKERS] Upcoming back-branch update releases

"Guillaume Smet" <guillaume.smet@gmail.com> writes:
> On Wed, May 28, 2008 at 4:10 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> If you've got any bug fixes you've been working on, now is a good time
>> to get them finished up and sent in...

> Has the s/\x09/ /g patch for psql from Bruce and you been
> backported to 8.3? I didn't see it on pgsql-commiters.

No, nothing's been done about that AFAIK. What's the consensus,
do we want to change that behavior in 8.3.2?

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Core team statement on replication in PostgreSQL

The Postgres core team met at PGCon to discuss a few issues, the largest
of which is the need for simple, built-in replication for PostgreSQL.
Historically the project policy has been to avoid putting replication
into core PostgreSQL, so as to leave room for development of competing
solutions, recognizing that there is no "one size fits all" replication
solution. However, it is becoming clear that this policy is hindering
acceptance of PostgreSQL to too great an extent, compared to the benefit
it offers to the add-on replication projects. Users who might consider
PostgreSQL are choosing other database systems because our existing
replication options are too complex to install and use for simple cases.
In practice, simple asynchronous single-master-multiple-slave
replication covers a respectable fraction of use cases, so we have
concluded that we should allow such a feature to be included in the core
project. We emphasize that this is not meant to prevent continued
development of add-on replication projects that cover more complex use
cases.

We believe that the most appropriate base technology for this is
probably real-time WAL log shipping, as was demoed by NTT OSS at PGCon.
We hope that such a feature can be completed for 8.4. Ideally this
would be coupled with the ability to execute read-only queries on the
slave servers, but we see technical difficulties that might prevent that
from being completed before 8.5 or even further out. (The big problem
is that long-running slave-side queries might still need tuples that are
vacuumable on the master, and so replication of vacuuming actions would
cause the slave's queries to deliver wrong answers.)

Again, this will not replace Slony, pgPool, Continuent, Londiste, or
other systems for many users, as it will be not be highly scalable nor
support long-distance replication nor replicating less than an entire
installation. But it is time to include a simple, reliable basic
replication feature in the core system.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[BUGS] BUG #4206: function xpath gives wrong results

The following bug has been logged online:

Bug reference: 4206
Logged by: Martin Drescher
Email address: martin.drescher@robotron.de
PostgreSQL version: 8.3.1
Operating system: Windows XP SP2
Description: function xpath gives wrong results
Details:

To demonstrate I use the following simple XML.

<?xml version="1.0"?>
<elem1>
<elem2>one</elem2>
<elem2>two</elem2>
<elem2>three</elem2>
<elem3 att="2"/>
</elem1>

I executed the following query in psql (with the corresponding XPath).

select xpath('//text()',xmlparse(document '<?xml version="1.0"
?><elem1><elem2>one</elem2><elem2>two</elem2><elem2>three</elem2><elem3
att="2"/></elem1>'));

The expected result is checked using Altova XMLSpy 2008.

XPath: (//text())[1]
Expected result: {one}
Actual Result:
ERROR: XX000: invalid XPath expression
DETAIL: Invalid expression
CONTEXT: SQL function "xpath" statement 1
LOCATION: xml_ereport, .\src\backend\utils\adt\xml.c:1351

XPath: boolean(/elem1)
Expected result: {true}
Actual Result:
ERROR: XX000: invalid XPath expression
DETAIL: Invalid expression
CONTEXT: SQL function "xpath" statement 1
LOCATION: xml_ereport, .\src\backend\utils\adt\xml.c:1351

XPath: /elem1/..
Expected result: document root
Actual Result:
{"<x>
<elem1>
<elem2>one</elem2>
<elem2>two</elem2>
<elem2>three</elem2>
<elem3 att=\"2\"/>
</elem1>
</x>"}

Note: This XPath returns the document root. I don’t know, how you choose
to represent it. However, it should not return the element <x>

The problem imo is in .\src\backend\utils\adt\xml.c:3294, where a
<x>-element is wrapped around the xml and the XPath-expression is prepended
by "/x".
This is not needed for XML documents and fragments consisting of a single
root. Instead it breaks many XPath-Expressions; like where you use multiple
absolute path expressions or function calls.
I think, queries on a fragment consisting of multiple roots are not possible
with XPath 1.0.

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [pgsql-www] 404s

On Wed, 2008-05-28 at 18:42 +0200, Stefan Kaltenbrunner wrote:

> I think it would be more reasonable to look into what it would take to
> remove the (obvious) false positives and have the mirror script report
> new ones automatically during site build.
> Though I think what simon was actually refering to are urls pointing to
> external sites which we could maybe check on events/training whatever
> submission and refuse to accept them.
> The mirroring does not really care for external sites so we would only
> be able to spot mistakes that lead to urls that end up on wwwmaster
> (like it being interpreted as a relative link or such) not ones that are
> broken otherwise (domain misspelled, simply wrong,...).

Specifically, yes. But I am worried that we aren't monitoring such a
basic quality issue. There might be lots of URLs in the Wiki that go bad
over time and we want to check on this, don't we?

--
Simon Riggs

www.2ndQuadrant.com

PostgreSQL Training, Services and Support

--
Sent via pgsql-www mailing list (pgsql-www@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www

Re: [COMMITTERS] pgsql: Add a field to guc enums to allow hiding of values from display

On Wed, May 28, 2008 at 8:33 AM, Magnus Hagander <magnus@hagander.net> wrote:
> Tom Lane wrote:
>> mha@postgresql.org (Magnus Hagander) writes:
>> > Add a field to guc enums to allow hiding of values from display
>> > while still accepting them as input, used to allow alternate syntax
>> > for the same setting.
>>
>> Aren't there some config_enum_entrys elsewhere (like xlog.c)?
>> I think they'd default to false, but still it'd be better practice
>> to fill them in.
>
> Hmm. I thought I was going to get warnings if I missed any, but it
> seems not. Will fix.
>

Oops I could have sworn i grepped the source for them... Sorry!

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Re: [PERFORM] GEQO Benchmark

On Wed, 2008-05-28 at 13:13 -0300, Tarcizio Bini wrote:

> Of course, the geqo_threshold can be changed so that the geqo be
> performed in queries that have less than 12 tables. However, we aim to
> test the GEQO algorithm in conditions where the standard algorithm
> (dynamic programming) has a high cost to calculate the query plan.

My understanding is the GEQO cannot arrive at a better plan than the
standard optimizer, so unless you wish to measure planning time there
isn't much to test. What is the quality of the plans it generates? Well
that varies according to the input; sometimes it gets the right plan,
other times it doesn't get close.

--
Simon Riggs

www.2ndQuadrant.com

PostgreSQL Training, Services and Support

--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

Re: [pgsql-www] 404s

Joshua D. Drake wrote:
>
> On Wed, 2008-05-28 at 18:23 +0200, Stefan Kaltenbrunner wrote:
>> Dave Page wrote:
>
>>> Probably because noone checked the log recently (we know if errors
>>> occur through other channels, but not 404 warnings).
>> well the logs still have a fair number of false positives.
>> This partly due to the mirror script being a bit careless at times in
>> what it should consider a valid url and the other part is url's that we
>> once had and referenced in say a press release that are no longer valid
>> (be it website reorg or a decision to rename directories on the ftp site).
>> otoh it seems that we have at least one really broken URL in the press
>> FAQ page - will see if we can fix that ...
>>
>
> What if we used a rewrite rule on 404 to actually bring up a single
> entry form that said, "Report broken page: <email> <submit>".

I think it would be more reasonable to look into what it would take to
remove the (obvious) false positives and have the mirror script report
new ones automatically during site build.
Though I think what simon was actually refering to are urls pointing to
external sites which we could maybe check on events/training whatever
submission and refuse to accept them.
The mirroring does not really care for external sites so we would only
be able to spot mistakes that lead to urls that end up on wwwmaster
(like it being interpreted as a relative link or such) not ones that are
broken otherwise (domain misspelled, simply wrong,...).

Stefan

--
Sent via pgsql-www mailing list (pgsql-www@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www

Re: FW: [pgsql-es-ayuda] Duda sql bases de datos

2008/5/28 Laura reiva <lauraleyton@hotmail.es>:
> Hola,
> La base de datos original no la puedo aumentar más pues ya contiene
> alrededor de cien tablas y debo realizar ésta "copia" con varias de ellas,
> por lo que crear una nueva tabla en la base de datos original para cada una
> de ellas sería muy complejo. Tendré que usar dblink, aunque no lo conozco.
> Tengo instalado postgreSQL 8.1. ¿Podría explicarme cómo funciona el producto
> dblink?

1ro. instalar dblink en la base de datos 1:

$psql -d db1 -U usuario -f /direccion/al/archivo/dblink.sql

2do. creas una función con un contenido parecido a este:

CREATE OR REPLACE FUNCTION dblink_db1_db2() RETURNS VOID AS $$
DECLARE
fila RECORD;
BEGIN

-- inicias la conexion
SELECT dblink_connect('dbname=db2 user=usuario password=contrasena');

-- obtienes los registros de la db1 (conexion actual) [puedes hacer
con cursores también]
FOR fila IN SELECT * FROM tablaAlumnos_db1 WHERE sexo = 'M' LOOP
-- insertas en la db2. fila: es la estructura que obtiene de cada
fila de la tabla
-- campo1,campo2,etc: son los atributos de la tabla de la 2da base.
SELECT dblink_exec('INSERT INTO tablaAlumnos_db2 VALUES(' ||
fila.campo1 || ',' || fila.campo2 || ');');
END LOOP;

-- cierras la conexion
SELECT dblink_disconnect();

END;
$$ LANGUAGE plpgsql;

3ro. ejecutas la función:

SELECT dblink_db1_db2();

Dale una leída a los archivos dentro de contrib/dblink/doc del código fuente.

--
Saludos y abrazos...

Marco Antonio Frias Butrón
Slackware Linux User
Linux Registered User #356229 - http://counter.li.org/
--
TIP 4: No hagas 'kill -9' a postmaster

Re: [GENERAL] Open Source CRM - Options?

On Wed, 2008-05-28 at 09:20 -0700, Steve Atkins wrote:
> On May 28, 2008, at 8:52 AM, David Wall wrote:
>
> > What about SugarCRM?
>

Drupal works fine with PostgreSQL :)

Joshua D. Drake

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Open Source CRM - Options?

On Tue, May 27, 2008 at 4:18 AM, Mark Neely <mark.neely@gmail.com> wrote:
> I've already shortlisted potential CMS systems (including several open-
> source options, such as Drupal and Joomla).

[snip...]

> I am looking for examples of open-source CRM (or similar platforms)
> used for this kind of profiling/personalisation, and would appreciate
> any pointers readers of this newsgroup might be able to offer.

I think the important question is whether the op means CMS or CRM
(quite different).

--
regards,
Robin

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [pgsql-www] replace training blurb with upcoming pug meetings?

On Wed, 2008-05-28 at 12:18 -0400, Robert Treat wrote:
> In an effort to give more visibility to the pugs, one idea that was floated
> around was replacing the training blurb on the main site with an "upcoming
> pugs" section, modeled after the upcoming events. The training blurb would
> then be changed to a direct link saying "looking for training?" (or similar)
> which would take you to the full training page. There are some logistical
> issues that would need to be worked out to make this happen, but before we go
> down that path, I wanted to get a general consensus on the idea. thoughts?

I would be amenable to that. I would like to see .Org focusing a bit
more on its "community".

Sincerely,

Joshua D. Drake

--
Sent via pgsql-www mailing list (pgsql-www@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www

Re: [pgsql-www] 404s

On Wed, 2008-05-28 at 18:23 +0200, Stefan Kaltenbrunner wrote:
> Dave Page wrote:

> > Probably because noone checked the log recently (we know if errors
> > occur through other channels, but not 404 warnings).
>
> well the logs still have a fair number of false positives.
> This partly due to the mirror script being a bit careless at times in
> what it should consider a valid url and the other part is url's that we
> once had and referenced in say a press release that are no longer valid
> (be it website reorg or a decision to rename directories on the ftp site).
> otoh it seems that we have at least one really broken URL in the press
> FAQ page - will see if we can fix that ...
>

What if we used a rewrite rule on 404 to actually bring up a single
entry form that said, "Report broken page: <email> <submit>".

Sincerely,

Joshua D. Drake

>
> Stefan
>

--
Sent via pgsql-www mailing list (pgsql-www@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www

Re: [pgsql-www] 404s

Dave Page wrote:
> On Wed, May 28, 2008 at 10:25 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> On Wed, 2008-05-28 at 10:09 +0100, Dave Page wrote:
>>> On Wed, May 28, 2008 at 9:55 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>>>> Do we keep track of 404 errors on the .org website?
>>> The spider logs internal errors (or used to, I haven't looked at
>>> recent versions). Why, did you find one?
>> Yes. I'm trying to understand why we didn't spot the 404s, nor perform a
>> link check that would do that.
>
> Probably because noone checked the log recently (we know if errors
> occur through other channels, but not 404 warnings).

well the logs still have a fair number of false positives.
This partly due to the mirror script being a bit careless at times in
what it should consider a valid url and the other part is url's that we
once had and referenced in say a press release that are no longer valid
(be it website reorg or a decision to rename directories on the ftp site).
otoh it seems that we have at least one really broken URL in the press
FAQ page - will see if we can fix that ...

Stefan

--
Sent via pgsql-www mailing list (pgsql-www@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www

[GENERAL] Clustering with minimal locking

If I'm not totally off-base, here's one way to enable clustering on systems
that run 24/7:

1 cluster current rows
1.1 note current last committed transaction
1.2 copy all visible rows to new table in cluster order
1.3 build indexes on new table
2 add changes
2.1 note current last committed transaction
2.2 apply to new table (& indexes) all changes committed since 1.1
3 put new table into service
3.1 take exclusive lock on table
3.2 apply to new table (& indexes) all changes committed since 2.1
3.3 switch in new table
3.4 release lock
3.5 clean up old table storage

I don't know enough about pg internals to know how big a project this would
be, but it seems to me that the WAL provides many of the pieces needed to
support steps 1.1 and 2.2, for instance. (Even so, I know it's still not
trivial, just perhaps not huge.)

- I guess there's still the possibility that 3.1 could stall in the presence
of long-lived transactions--but this is certainly no worse than the current
situation where it would stall before starting the cluster operation.

- By "apply changes" I mean insert, update, delete rows--of course schema
changes would be locked out during the cluster, even if it takes days ;-)

--
Scott Ribe
scott_ribe@killerbytes.com
http://www.killerbytes.com/
(303) 722-0567 voice

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Open Source CRM - Options?

On May 28, 2008, at 8:52 AM, David Wall wrote:

> What about SugarCRM?

It's nice, but it's MySQL only, with a few desiccated corpses of ports
to PostgreSQL done by third parties littered in it's wake.

vTiger is a fork / knock-off of Sugar which has sorta-kinda support
for PostgreSQL in older versions, but not in the current version. http://wiki.postgresql.org/wiki/VTigerCRM

Cheers,
Steve

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[pgsql-www] replace training blurb with upcoming pug meetings?

In an effort to give more visibility to the pugs, one idea that was floated
around was replacing the training blurb on the main site with an "upcoming
pugs" section, modeled after the upcoming events. The training blurb would
then be changed to a direct link saying "looking for training?" (or similar)
which would take you to the full training page. There are some logistical
issues that would need to be worked out to make this happen, but before we go
down that path, I wanted to get a general consensus on the idea. thoughts?

--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

--
Sent via pgsql-www mailing list (pgsql-www@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www

Re: [PERFORM] GEQO Benchmark

Hi,

Of course, the geqo_threshold can be changed so that the geqo be performed in queries that have less than 12 tables. However, we aim to test the GEQO algorithm in conditions where the standard algorithm (dynamic programming) has a high cost to calculate the query plan.

--

Tarcizio Bini

2008/5/28 Tom Lane <tgl@sss.pgh.pa.us>:

tarcizioab@c3sl.ufpr.br writes:
> I'm using the TPC-H Benchmark for testing of performance in PostgreSQL.
> But it is composed of only 8 tables, which is not enough to call the GEQO
> algorithm.

See
http://www.postgresql.org/docs/8.3/static/runtime-config-query.html#RUNTIME-CONFIG-QUERY-GEQO

particularly geqo_threshold.

                       regards, tom lane

Re: [pgsql-es-ayuda] Instalacion desatendida

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Esto te puede ayudar:

http://pginstaller.projects.postgresql.org/silent.html

Lo que hace una búsqueda en google :D....

Ing. Eris J. Gomez escribió:
| Saludos al grupo.
| Esta vez tengo una pregunta, aunque no meramente de SQL, sino de
instalación desatendida.
| Como puedo especificar los parámetros para que Postgres se auto
instale es decir, que el usuario no tenga que digitar ninguna
información sino que yo las establezca.
|
| Gracias.
| *
|
| Ing. Eris J. Gómez
| Racol Computers, C x A.
| Símbolo de calidad en software.
| Av. 27 de febrero #37, Villa Progreso
| Santiago de los Caballeros, República Dominicana
| Tel.: (809) 971-3157, Fax: (809) 582-6636
| Email: racolsoftware@hotmail.com <mailto:racolsoftware@hotmail.com>
| *
|
| -------------------------
|
| --
| TIP 7: no olvides aumentar la configuración del "free space map"

- --
-
-------------------------------------------------------------------------------------------------
L.A. Jenaro Centeno Gómez Al-Día se
renueva con la Mejora Continua
Coordinador de Tecnologías de la Información
Alimentos La Concordia, S.A. de C.V.
www.aldia.com.mx

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIPYOl+nACvgizD48RAkGDAJoD8mxIEsZvyLUIggeosZ6pDpLtRwCgqabI
TWAO6gL9W3r3KV7ra4Klw/E=
=4I9u
-----END PGP SIGNATURE-----

--
TIP 4: No hagas 'kill -9' a postmaster

Re: [pgsql-es-ayuda] Instalacion desatendida

El día 28 de mayo de 2008 10:02, Ing. Eris J. Gomez
<eris_jose@hotmail.com> escribió:
> Saludos al grupo.
> Esta vez tengo una pregunta, aunque no meramente de SQL, sino de instalación
> desatendida.
> Como puedo especificar los parámetros para que Postgres se auto instale es
> decir, que el usuario no tenga que digitar ninguna información sino que yo
> las establezca.

eso depende del sistema operativo y los parámetros que deseas establecer....
--
TIP 10: no uses HTML en tu pregunta, seguro que quien responda no podrá leerlo

Re: [pgsql-es-ayuda] PostgreSQL en Chile, jornadas

2008/5/28 Guido Barosio <gbarosio@gmail.com>:
> Desconozco, sinceramente me llego la nota y la comparti con el grupo.
>
> Quizas Alvaro o alguno de los chicos de Chile nos pueda dar una idea
>

solo preguntaba porque no se menciona en la nota.
--
TIP 4: No hagas 'kill -9' a postmaster

Re: [pgsql-es-ayuda] Problema con execute

mil gracias a todos.. anduvo perfecto.
saludazos.

__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
¡Abrí tu cuenta ya! - http://correo.yahoo.com.ar

RE: [pgsql-es-ayuda] sobre ALTER TABLE

OK, OK, OK............

No lo habia leido bien, crei que pensaba "rescatar" algun valor del campo
TIME, pero que valor va a rescatar si no hay nada que rescatar de tipo DATE,
lo mas saludable y menos complicado y perder menos tiempo es dropearlo y
poner el campo que se necesite.

Miguel Canchas

-----Mensaje original-----
De: Jaime Casanova [mailto:systemguards@gmail.com]
Enviado el: Miércoles, 28 de Mayo de 2008 10:41 a.m.
Para: MIGUEL CANCHAS
CC: Marcos Saldivar; Mario Reyes (GENESYS);
pgsql-es-ayuda@postgresql.org
Asunto: Re: [pgsql-es-ayuda] sobre ALTER TABLE

On Wed, May 28, 2008 at 10:28 AM, MIGUEL CANCHAS <mcanchas@tsr.com.pe>
wrote:
> no seria mejor crear una columna con el tipo de dato que necesita y
> adicionarle los datos "casteados" desde la columna a "dropear"
>

y como harias el cast? si eres capaz de "castearlos" entonces puedes
usar la clausula USING del ALTER TABLE ... ALTER ... TYPE para hacer
el trabajo, sin columnas adicionales ni drops

--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Guayaquil - Ecuador
Cel. (593) 087171157
--
TIP 8: explain analyze es tu amigo

Re: [GENERAL] Open Source CRM - Options?

What about SugarCRM?

David

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Psql crashes with Segmentation fault on copy from

On 11:09 am 05/28/08 Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > I installed
> > compat-postgresql-libs-debuginfo-3-2PGDG.rhel4.x86_64.rpm
> > postgresql-debuginfo-8.2.7-1PGDG.rhel4.x86_64.rpm
>
> Do those *exactly* match the versions of the Postgres RPMs you're
> using?

I got them from the same directory as the rest of the 8.2.7 RPMs I
downloaded.

I am going to try uninstalling the RPMs and using the Source RPMS and
report back. There is no production data yet since I am working on testing
the machine and creating some benchmarks so I can redo the entire setup as
needed.

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [pgsql-es-ayuda] sobre ALTER TABLE

On Wed, May 28, 2008 at 10:28 AM, MIGUEL CANCHAS <mcanchas@tsr.com.pe> wrote:
> no seria mejor crear una columna con el tipo de dato que necesita y
> adicionarle los datos "casteados" desde la columna a "dropear"
>

y como harias el cast? si eres capaz de "castearlos" entonces puedes
usar la clausula USING del ALTER TABLE ... ALTER ... TYPE para hacer
el trabajo, sin columnas adicionales ni drops

--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Guayaquil - Ecuador
Cel. (593) 087171157
--
TIP 7: no olvides aumentar la configuración del "free space map"

Re: [pgsql-es-ayuda] PostgreSQL en Chile, jornadas

Desconozco, sinceramente me llego la nota y la comparti con el grupo.

Quizas Alvaro o alguno de los chicos de Chile nos pueda dar una idea

Saludos!
gb.-

On Wed, May 28, 2008 at 6:08 AM, Marcos Saldivar
<baron.rojo.cuerdas.de.acero@gmail.com> wrote:
> El día 28 de mayo de 2008 8:52, Guido Barosio <gbarosio@gmail.com> escribió:
>> FYI
>>
>> http://www.transmedia.cl/noticia12=id270508.htm
>
> entrada liberada ?
>
>>
>> --
>> Guido Barosio
>> -----------------------
>> http://www.globant.com
>> guido.barosio@globant.com
>> --
>> TIP 9: visita nuestro canal de IRC #postgresql-es en irc.freenode.net
>>
>

--
Guido Barosio
-----------------------
http://www.globant.com
guido.barosio@globant.com
--
TIP 10: no uses HTML en tu pregunta, seguro que quien responda no podrá leerlo

Re: [pgsql-es-ayuda] Uso de ora2pg

2008/5/28 Richard Velasquez <rjvelasq@gmail.com>:

> Can't locate String/Random.pm in @INC (@INC contains: D:/Perl/site/lib
> D:/Perl/lib .) at Ora2Pg.pm line 1041.

Debes instalar el módulo "String::Random"[1]. Supongo que tienes el
perl de Activestate y este debe tener alguna herramienta automatizada
para este proceso. Lo siento, no puedo ser más específico porque no
uso perl en win.

> Si algunos de ustedes tiene documentación sobre el uso de éste script le
> agradezco enviármela por favor.

Y del perl supongo ;)

--
Saludos,
PP

[1] http://search.cpan.org/~steve/String-Random-0.22/lib/String/Random.pm
--
TIP 9: visita nuestro canal de IRC #postgresql-es en irc.freenode.net

[DOCS] psqlODBC homepage bad link on http://www.postgresql.org/docs/8.2/static/external-interfaces.html

http://odbc.postgresql.org/ no longer exists?

----
James Robinson
Socialserve.com

--
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

RE: [pgsql-es-ayuda] sobre ALTER TABLE

no seria mejor crear una columna con el tipo de dato que necesita y
adicionarle los datos "casteados" desde la columna a "dropear"

Miguel Canchas

-----Mensaje original-----
De: Marcos Saldivar [mailto:baron.rojo.cuerdas.de.acero@gmail.com]
Enviado el: Miércoles, 28 de Mayo de 2008 10:25 a.m.
Para: Jaime Casanova
CC: Mario Reyes (GENESYS); pgsql-es-ayuda@postgresql.org
Asunto: Re: [pgsql-es-ayuda] sobre ALTER TABLE

2008/5/28 Jaime Casanova <systemguards@gmail.com>:
> On Wed, May 28, 2008 at 8:22 AM, Marcos Saldivar
> <baron.rojo.cuerdas.de.acero@gmail.com> wrote:
>> 2008/5/28 Jaime Casanova <systemguards@gmail.com>:
>>> On Tue, May 27, 2008 at 11:00 PM, Mario Reyes (GENESYS)
>>> <Genesys3@celulosa.cmpc.cl> wrote:
>>>>
>>>> ALTER TABLE "public"."presupuestos" ALTER COLUMN "pres_fecha_inicio"
TYPE
>>>> DATE;
>>>>
>>>> ERROR: column "pres_fecha_inicio" cannot be cast to type "date"
>>>>
>>>> La pregunta por lo tanto es Cual es la manera correcta de hacer el
Cast?. He
>>>> intentado con el USING de acuerdo a la documentación.
>>>>
>>>> ALTER TABLE "public"."presupuestos" ALTER COLUMN "pres_fecha_inicio"
TYPE
>>>> date USING "pres_fecha_inicio"::date;
>>>>
>>>> Sin embargo aparece otro error:
>>>> ERROR: cannot cast type time without time zone to date
>>>> (0,547 sec)
>>>>
>>>
>>> Si en esa columna aun no has grabado ningun dato, puedes hacer:
>>> ALTER TABLE "public"."presupuestos"
>>> ALTER COLUMN "pres_fecha_inicio" TYPE date USING NULL;
>>>
>>> Si ya hay datos, ahi si esta fregada la cosa...
>>
>> por qué ? acaso no puede hacer un simple drop de esa columna ?
>
> si, se puede...
> pero el ALTER TABLE tambien funciona con el USING NULL aunque tenga
> datos la columna, pero pierde los datos
>
>> imagino que si necesita un date, no puede tener mas que poca valides
>> la info de esa columna si es time
>
> ese es mi punto, esos datos son como poco no validos y seguramente no
> habra forma segura o confiable de recuperarlos como date... en otras
> palabras que ya los perdio...

entonces que use lo que le recomiendas que es mucho mas elegante que
lo que hacia yop de un drop column y luego un add column je je je

ALTER TABLE "public"."presupuestos" ALTER COLUMN "pres_fecha_inicio"
TYPE date USING NULL;

saludos.-

>
>
> --
> Atentamente,
> Jaime Casanova
> Soporte y capacitación de PostgreSQL
> Guayaquil - Ecuador
> Cel. (593) 087171157
>
--
TIP 6: ¿Has buscado en los archivos de nuestra lista de correo?

http://archives.postgresql.org/pgsql-es-ayuda
--
TIP 1: para suscribirte y desuscribirte, visita http://archives.postgresql.org/pgsql-es-ayuda

Re: [pgsql-es-ayuda] sobre ALTER TABLE

2008/5/28 Jaime Casanova <systemguards@gmail.com>:
> On Wed, May 28, 2008 at 8:22 AM, Marcos Saldivar
> <baron.rojo.cuerdas.de.acero@gmail.com> wrote:
>> 2008/5/28 Jaime Casanova <systemguards@gmail.com>:
>>> On Tue, May 27, 2008 at 11:00 PM, Mario Reyes (GENESYS)
>>> <Genesys3@celulosa.cmpc.cl> wrote:
>>>>
>>>> ALTER TABLE "public"."presupuestos" ALTER COLUMN "pres_fecha_inicio" TYPE
>>>> DATE;
>>>>
>>>> ERROR: column "pres_fecha_inicio" cannot be cast to type "date"
>>>>
>>>> La pregunta por lo tanto es Cual es la manera correcta de hacer el Cast?. He
>>>> intentado con el USING de acuerdo a la documentación.
>>>>
>>>> ALTER TABLE "public"."presupuestos" ALTER COLUMN "pres_fecha_inicio" TYPE
>>>> date USING "pres_fecha_inicio"::date;
>>>>
>>>> Sin embargo aparece otro error:
>>>> ERROR: cannot cast type time without time zone to date
>>>> (0,547 sec)
>>>>
>>>
>>> Si en esa columna aun no has grabado ningun dato, puedes hacer:
>>> ALTER TABLE "public"."presupuestos"
>>> ALTER COLUMN "pres_fecha_inicio" TYPE date USING NULL;
>>>
>>> Si ya hay datos, ahi si esta fregada la cosa...
>>
>> por qué ? acaso no puede hacer un simple drop de esa columna ?
>
> si, se puede...
> pero el ALTER TABLE tambien funciona con el USING NULL aunque tenga
> datos la columna, pero pierde los datos
>
>> imagino que si necesita un date, no puede tener mas que poca valides
>> la info de esa columna si es time
>
> ese es mi punto, esos datos son como poco no validos y seguramente no
> habra forma segura o confiable de recuperarlos como date... en otras
> palabras que ya los perdio...

entonces que use lo que le recomiendas que es mucho mas elegante que
lo que hacia yop de un drop column y luego un add column je je je

ALTER TABLE "public"."presupuestos" ALTER COLUMN "pres_fecha_inicio"
TYPE date USING NULL;

saludos.-

>
>
> --
> Atentamente,
> Jaime Casanova
> Soporte y capacitación de PostgreSQL
> Guayaquil - Ecuador
> Cel. (593) 087171157
>
--
TIP 6: ¿Has buscado en los archivos de nuestra lista de correo?

http://archives.postgresql.org/pgsql-es-ayuda

Re: [pgsql-es-ayuda] Capturar transacciones durante un día

2008/5/28 Raul Andres Duque <ra_duque@yahoo.com.mx>:
> 4. Capturar TODAS las operaciones lectura/escritura realizadas por ejemplo
> durante un día.

Lo mejor que puedes hacer poner log_statement = all en
postgresql.conf, esto registrara en el log todas las sentencias
excepto las que tengan error de sintaxis... quiza se te facilite las
cosas si envias el log en formato cvs y lo subes a una tabla (esto es
posible desde 8.3)
http://www.postgresql.org/docs/current/static/runtime-config-logging.html#RUNTIME-CONFIG-LOGGING-CSVLOG

--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Guayaquil - Ecuador
Cel. (593) 087171157
--
TIP 10: no uses HTML en tu pregunta, seguro que quien responda no podrá leerlo

[COMMITTERS] pgsql: Set hidden field for guc enum missed in previous commit.

Log Message:
-----------
Set hidden field for guc enum missed in previous commit.

Modified Files:
--------------
pgsql/src/backend/access/transam:
xlog.c (r1.311 -> r1.312)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/transam/xlog.c?r1=1.311&r2=1.312)

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Re: [HACKERS] Remove redundant extra_desc info for enum GUC variables?

Magnus Hagander <magnus@hagander.net> writes:
> Tom Lane wrote:
>> Yeah: LOG level sorts differently in the two cases; it's fairly high
>> priority for server log output and much lower for client output.

> Ok, easy fix if we break them apart. Should we continue to accept
> values that we're not going to care about, or should I change that at
> the same time? (for example, client_min_messages doesn't use INFO,
> but we do accept that in <= 8.3 anyway)

I'd be inclined to keep the actual behavior the same as it was.
We didn't document INFO for this variable, perhaps, but it's accepted
and has a well-defined behavior.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Add dblink function to check if a named connection exists

Tommy Gildseth <tommy.gildseth@usit.uio.no> writes:
> One obvious disadvantage of this approach, is that I need to connect and
> disconnect in every function. A possible solution to this, would be
> having a function f.ex dblink_exists('connection_name') that returns
> true/false depending on whether the connection already exists.

Can't you do this already?

SELECT 'myconn' = ANY (dblink_get_connections());

A dedicated function might be a tad faster, but it probably isn't going
to matter compared to the overhead of sending a remote query.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[pgsql-es-ayuda] Uso de ora2pg

Buenos Días

Estoy probando el script ora2pg para hacer migración de esquemas de bd oracle a postgres y me da el siguiente error

Can't locate String/Random.pm in @INC (@INC contains: D:/Perl/site/lib D:/Perl/lib .) at Ora2Pg.pm line 1041.
BEGIN failed--compilation aborted at Ora2Pg.pm line 1041.
Compilation failed in require at ora2pg.pl line 16.
BEGIN failed--compilation aborted at ora2pg.pl line 16.

Si algunos de ustedes tiene documentación sobre el uso de éste script le agradezco enviármela por favor.


Saludos,

Atte,

Richard Velásquez
Venezuela.

Re: [pgsql-es-ayuda] sobre ALTER TABLE

On Wed, May 28, 2008 at 8:22 AM, Marcos Saldivar
<baron.rojo.cuerdas.de.acero@gmail.com> wrote:
> 2008/5/28 Jaime Casanova <systemguards@gmail.com>:
>> On Tue, May 27, 2008 at 11:00 PM, Mario Reyes (GENESYS)
>> <Genesys3@celulosa.cmpc.cl> wrote:
>>>
>>> ALTER TABLE "public"."presupuestos" ALTER COLUMN "pres_fecha_inicio" TYPE
>>> DATE;
>>>
>>> ERROR: column "pres_fecha_inicio" cannot be cast to type "date"
>>>
>>> La pregunta por lo tanto es Cual es la manera correcta de hacer el Cast?. He
>>> intentado con el USING de acuerdo a la documentación.
>>>
>>> ALTER TABLE "public"."presupuestos" ALTER COLUMN "pres_fecha_inicio" TYPE
>>> date USING "pres_fecha_inicio"::date;
>>>
>>> Sin embargo aparece otro error:
>>> ERROR: cannot cast type time without time zone to date
>>> (0,547 sec)
>>>
>>
>> Si en esa columna aun no has grabado ningun dato, puedes hacer:
>> ALTER TABLE "public"."presupuestos"
>> ALTER COLUMN "pres_fecha_inicio" TYPE date USING NULL;
>>
>> Si ya hay datos, ahi si esta fregada la cosa...
>
> por qué ? acaso no puede hacer un simple drop de esa columna ?

si, se puede...
pero el ALTER TABLE tambien funciona con el USING NULL aunque tenga
datos la columna, pero pierde los datos

> imagino que si necesita un date, no puede tener mas que poca valides
> la info de esa columna si es time

ese es mi punto, esos datos son como poco no validos y seguramente no
habra forma segura o confiable de recuperarlos como date... en otras
palabras que ya los perdio...

--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Guayaquil - Ecuador
Cel. (593) 087171157
--
TIP 5: ¿Has leído nuestro extenso FAQ?

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

Re: [GENERAL] Open Source CRM - Options?

kaloyan@digsys.bg (Kaloyan Iliev) writes:
> And what about RT (Request Tracker - http://bestpractical.com/rt/)
> .
> AFAIK it is free and open-source, uses Postgres and is easy to setup.

RT has a very different purpose; it was designed to track work (e.g. -
"work tickets"), as opposed to managing web site content.

It *might* be used as a bug tracker, though with a considerably
different flavour from (say) Bugzilla; as a CRM, it would be pretty
unsuitable :-(.
--
output = reverse("moc.enworbbc" "@" "enworbbc")
http://cbbrowne.com/info/lisp.html
"Listen, strange women, lyin' in ponds, distributin' swords, is no
basis for a system of government. Supreme executive power derives
itself from a mandate from the masses, not from some farcical aquatic
ceremony." -- Monty Python and the Holy Grail

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Psql crashes with Segmentation fault on copy from

"Francisco Reyes" <lists@stringsutils.com> writes:
> (gdb) bt
> #0 0x0000003cc31723e6 in memcpy () from /lib64/tls/libc.so.6
> #1 0x000000364bf0e0ae in PQunescapeBytea () from /usr/lib64/libpq.so.5
> #2 0x000000364bf0e230 in PQunescapeBytea () from /usr/lib64/libpq.so.5
> #3 0x000000364bf0c09e in PQsendQuery () from /usr/lib64/libpq.so.5
> #4 0x000000364bf0c788 in PQexec () from /usr/lib64/libpq.so.5
> #5 0x0000000000406e95 in ?? ()
> #6 0x0000000000409dfa in ?? ()
> #7 0x000000000040408d in ?? ()

> Is that what you need?

Well, it would be if it were right; but PQsendQuery doesn't call
PQunescapeBytea, so there's something wrong with the debug info.
(The fact that we're not seeing any parameter values is another
tip that it's not right. Apparently gdb doesn't think the debuginfo
matches at all.)

> I installed
> compat-postgresql-libs-debuginfo-3-2PGDG.rhel4.x86_64.rpm
> postgresql-debuginfo-8.2.7-1PGDG.rhel4.x86_64.rpm

Do those *exactly* match the versions of the Postgres RPMs you're
using?

regards, tom lane

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [pgus-board] Feedback on draft bylaws

Michael Alan Brewer wrote:
> Other than Josh Berkus, has anyone else yet chimed in on the review
> bylaws? Admittedly, we're in a short work week (plus the week after
> PgCon); do we need to poke announce or planet?

To my knowledge we have only received feedback from Josh Berkus. I don't
think we should poke planet but perhaps a small email that is not part
of the existing thread as a reminder would be good.

Sincerely,

Joshua D. Drake

--
Sent via pgus-board mailing list (pgus-board@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgus-board

Re: [GENERAL] Psql crashes with Segmentation fault on copy from

On 6:28 pm 05/27/08 Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Can you get us a stack trace from the crash?

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 182894175648 (LWP 4487)]
0x0000003cc31723e6 in memcpy () from /lib64/tls/libc.so.6
(gdb) bt
#0 0x0000003cc31723e6 in memcpy () from /lib64/tls/libc.so.6
#1 0x000000364bf0e0ae in PQunescapeBytea () from /usr/lib64/libpq.so.5
#2 0x000000364bf0e230 in PQunescapeBytea () from /usr/lib64/libpq.so.5
#3 0x000000364bf0c09e in PQsendQuery () from /usr/lib64/libpq.so.5
#4 0x000000364bf0c788 in PQexec () from /usr/lib64/libpq.so.5
#5 0x0000000000406e95 in ?? ()
#6 0x0000000000409dfa in ?? ()
#7 0x000000000040408d in ?? ()
#8 0x00000000004057cd in ?? ()
#9 0x0000000000406286 in ?? ()
#10 0x0000000000409f66 in ?? ()
#11 0x000000000040408d in ?? ()
#12 0x00000000004057cd in ?? ()
#13 0x0000000000406286 in ?? ()
#14 0x0000000000409f66 in ?? ()
#15 0x000000000040c687 in ?? ()
#16 0x0000003cc311c3fb in __libc_start_main () from /lib64/tls/libc.so.6
#17 0x0000000000403d2a in ?? ()
#18 0x0000007fbffff558 in ?? ()
#19 0x000000000000001c in ?? ()
#20 0x0000000000000001 in ?? ()
#21 0x0000007fbffff795 in ?? ()
#22 0x0000000000000000 in ?? ()

Is that what you need?
I installed
compat-postgresql-libs-debuginfo-3-2PGDG.rhel4.x86_64.rpm
postgresql-debuginfo-8.2.7-1PGDG.rhel4.x86_64.rpm

What is compat-postgresql-libs-debuginfo?
Neither of those two RPMs are described in the RPM install PDF by Devrim
and Lamar.

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[pgsql-es-ayuda] Re: [pgsql-es-ayuda] Capturar transacciones durante un día

--------------------------------------------------
From: "Marcos Saldivar" <baron.rojo.cuerdas.de.acero@gmail.com>
Sent: Wednesday, May 28, 2008 8:43 AM
To: "Raul Andres Duque" <ra_duque@yahoo.com.mx>
Cc: <pgsql-es-ayuda@postgresql.org>
Subject: Re: [pgsql-es-ayuda] Capturar transacciones durante un día

> El día 28 de mayo de 2008 9:30, Raul Andres Duque
> <ra_duque@yahoo.com.mx> escribió:
>> Cordial Saludo.
>>
>> Quisiera generar unos benchmarks de mi base de datos pero generado a
>> partir
>> de por ejemplo las operaciones realizadas durante un día. Mi idea es:
>>
>> 1. Restringir la conexiones (asegurar que NADIE modifique mi DB)
>> 2. Generar un backup full de la DB.
>> 3. Habilitar nuevamente las conexiones a mi DB de producción
>> 4. Capturar TODAS las operaciones lectura/escritura realizadas por
>> ejemplo
>> durante un día.
>> 5. Restaurar una copia de mi DB original.
>> 6. Ejecutar las mismas operaciones en el backup restaurado de mi DB
>> original
>> (midiendo tiempos).
>> 7. Cambiar configuración de mi DB
>> 8. Repetir los pasos 4-6 para las pruebas que quiera realizar.
>>
>> La ayuda que pido es qué herramientas podrían ayudarme en mi tarea.
>>
>> De inicio tengo estas pregunta:
>>
>> ¿Cómo puedo capturar las operaciones realizadas por la DB de una forma
>> más
>> adecuada para ser reproducida/ejecutada que la que me suministra el log
>> de
>> postgresql (me tocaría quitar las columnas de fecha/hora y hacer otras
>> cosillas para dejarlo de forma adecuada para ser ejecutada por el psql).?
>>
>> ¿Qué herramienta me podría ayudar en la generación de estadísticas o
>> tabulación de los tiempos de respuesta obtenidos en las operaciones, por
>> ejemplo dividiéndolas por escrituras/lecturas, por tabla, por ubndices,
>> seqscan, por tiempo de ejecucción ,etc?
>>
>> Espero que mi idea no sea muy loca que digamos ... pero más o menos así
>> es
>> que trabaja el PERFORMANCE ADVISOR DE MSSQL.
>
> me quedo la duda si esto lo vas hacer en un db de producción ? porque
> para mi inocente cabecita y inexperta, esto es demasiado arriesgado de
> bajar conexiones hacer dump y restaurar una db en producción...
>
> saludos.-
>
> ps: porque no partir de algo mas sencillo como un catastro de todas
> las query's que hace el o los sistemas y partir por ahí o partir por
> donde los usuarios reclaman ???
>

No .. la idea es hacer en una DB de pruebas (apartir de una Db de producción
restaurada)..

Esta bien lo que dices, sin embargo mi prueba va tambien a ver el efecto de
diferentes cambios de configuración, por lo que require que se reproduzca
TODA la aoperación para que las operaciones sea consistentes.

Atentamente,

RAUL DUQUE
Bogotá, Colombia

>>
>> Gracias.
>>
>> Atentamente,
>>
>> RAUL DUQUE
>> Bogotá, Colombia
>
> __________ Information from ESET Smart Security, version of virus
> signature database 3139 (20080528) __________
>
> The message was checked by ESET Smart Security.
>
> http://www.eset.com
>
>
--
TIP 10: no uses HTML en tu pregunta, seguro que quien responda no podrá leerlo

[ADMIN] psql var ON_ERROR_ROLLBACK effect in pg_restore

Hello list,
I don't found anything about that in the archives, so...
I need to restore an binary backup that is generating errors.
The pg_restore utility is doing a rollback when he found errors.
Can i stop this?
With the psql utility i just set the ON_ERROR_ROLLBACK to get this effect.
Is that possible?
Sorry about my bad english.

--
Álvaro Guimarães
Santa Bárbara D'Oeste - SP - Brazil

Re: [HACKERS] pg_regress: dbname in PostgreSQL test suite

Jorgen Austvik - Sun Norway wrote:
> Hi.
>
> pg_regress has a --dbname option (which actually take a list of
> database names):
>
> --dbname=DB use database DB (default \"regression\")
>
> ... but the PostgreSQL regression test suite does not really support
> this:
>
> [jaustvik@host:regress] ggrep -R "regression" sql/* | grep -v
> regression_ | grep -v :--
> sql/prepare.sql:EXECUTE q2('regression');
> sql/privileges.sql:\c regression
> sql/temp.sql:\c regression
>
> I suggest we replace @dbname@ with the first element in the dblist
> linked list in convert_sourcefiles_in(). What do you think?
>
> (I can provide a patch if you think it is an acceptable solution.)
>
>

We have more than one set of regression tests. This feature is used by
the PL regression tests and the contrib regression tests to run using a
different database name.

I'm not quite sure why it's a list.

cheers

andrew

cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [COMMITTERS] pgsql: Add a field to guc enums to allow hiding of values from display

Tom Lane wrote:
> mha@postgresql.org (Magnus Hagander) writes:
> > Add a field to guc enums to allow hiding of values from display
> > while still accepting them as input, used to allow alternate syntax
> > for the same setting.
>
> Aren't there some config_enum_entrys elsewhere (like xlog.c)?
> I think they'd default to false, but still it'd be better practice
> to fill them in.

Hmm. I thought I was going to get warnings if I missed any, but it
seems not. Will fix.

//Magnus

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Re: [HACKERS] pg_regress: dbname in PostgreSQL test suite

Jorgen Austvik - Sun Norway <Jorgen.Austvik@Sun.COM> writes:
> pg_regress has a --dbname option (which actually take a list of database
> names):

> --dbname=DB use database DB (default \"regression\")

> ... but the PostgreSQL regression test suite does not really support this:

That option is intended for running other sets of regression tests
(eg, the contrib ones are customarily run in contrib_regression).
I see zero value in trying to make the standard tests run under
some other database name.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] pg_regress: referencing shared objects from tests

Jorgen Austvik - Sun Norway <Jorgen.Austvik@Sun.COM> writes:
> we would like to be able to use and ship pg_regress and the PostgreSQL
> test suite independently of the PostgreSQL build environment, for
> testing and maybe even as a separate package to be build and shipped
> with the OS for others to test their setup. Does this sound like a sane
> and OK thing to do?

The RPM packages have done this since approximately forever. You might
want to look at the patches used there.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [JDBC] How embarrassing: optimization of a one-shot query doesn't work

Dave Cramer <pg@fastcrypt.com> writes:
> On 23-May-08, at 9:20 AM, Tom Lane wrote:
>> There was some discussion a week or so back about scheduling a set of
>> releases in early June, but it's not formally decided.

> Now that PGCon is over has there been any more discussion ?

Yeah, I just posted an announcement about it on -hackers.

regards, tom lane

--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc

Re: [COMMITTERS] pgsql: Add a field to guc enums to allow hiding of values from display

mha@postgresql.org (Magnus Hagander) writes:
> Add a field to guc enums to allow hiding of values from display while
> still accepting them as input, used to allow alternate syntax for the
> same setting.

Aren't there some config_enum_entrys elsewhere (like xlog.c)?
I think they'd default to false, but still it'd be better practice
to fill them in.

regards, tom lane

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Re: [torontopug] Toronto PU[GB]

The mailing list should be up real soon now(TM), and I should become
the admin as well. In the meantime, the archives appear to be up now,
which is how I found out I still appear to be not subscribed:

http://archives.postgresql.org/torontopug/

Thanks for putting together that table Steve. I'd just like to add
that there are Rails nights on the second Tuesday and third Monday's
of the month. I agree that we should try and stick to early week as
well. Based on what we've got so far, how does the 4th Monday of the
month sound? The chance of it falling on a holiday is pretty low,
except for Christmas (around which people are pretty busy anyways). It
doesn't appear to conflict with anything that I can find.

~Ian

On Tue, May 27, 2008 at 10:48 PM, Steve Singer <ssinger_pg@sympatico.ca> wrote:
>
> On Tue, 27 May 2008, [utf-8] Jonathan Fuerth wrote:
>
> I looked at some of the local user groups with regularly scheduled meetings. That second week is already pretty active. I also suspect pubs will be more accomidating on a Monday,Tuesday or Wednesday.
>
> M T W T F
> 1 J
> 2 A L U
> 3 P B
> 4 p
>
> p=Perl
> P=Python
> J=Java User group
> L=Toronto Lug
> U=Unix Unanimous
> B=gtabug
> A=Ajax pub night
> Ruby: Second sunday of each month
>
> http://gtalug.org/wiki/Other_Opensource_Computing_groups
> http://www.geekstreet.ca/usergroups.php
>
>> To throw out another option, I've been attending GTABUG regularly for years. We've had a great experience at Olympic 76 Pizza (near Yonge and Bloor). Friendly staff, good pizza, and 3 kinds of beer on tap. GTABUG meets there on the 3rd Wednesday of evey month. A number of GTABUG regulars are PostgreSQL enthusiasts.
>>
>> There's also a long-standing group, "Unix Unanimous," that meets on the second Wednesday of the month. They start the evening in a small lecture room at UofT, then go for dinner as a group at a restaurant near Bloor and Spadina. I bring this up because a number of PostgreSQL enthusiasts also regularly attend that meeting.
>>
>> -Jonathan

--
Sent via torontopug mailing list (torontopug@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/torontopug

[HACKERS] pg_regress: dbname in PostgreSQL test suite

begin:vcard
fn;quoted-printable:J=C3=B8rgen Austvik
n;quoted-printable:Austvik;J=C3=B8rgen
org:Sun Microsystems;Database Group
adr:;;Haakon VII gt. 7b;Trondheim;;NO-7485;Norway
email;internet:jorgen.austvik@sun.com
title:Senior Engineer
tel;work:+47 73 84 21 10
tel;fax:+47 73 84 21 01
tel;cell:+47 901 97 886
note:http://www.austvik.net/
x-mozilla-html:FALSE
url:http://blogs.sun.com/austvik/
version:2.1
end:vcard

Hi.

pg_regress has a --dbname option (which actually take a list of database
names):

--dbname=DB use database DB (default \"regression\")

... but the PostgreSQL regression test suite does not really support this:

[jaustvik@host:regress] ggrep -R "regression" sql/* | grep -v
regression_ | grep -v :--
sql/prepare.sql:EXECUTE q2('regression');
sql/privileges.sql:\c regression
sql/temp.sql:\c regression

I suggest we replace @dbname@ with the first element in the dblist
linked list in convert_sourcefiles_in(). What do you think?

(I can provide a patch if you think it is an acceptable solution.)

-J
--

Jørgen Austvik, Software Engineering - QA
Sun Microsystems Database Group

http://blogs.sun.com/austvik/
http://www.austvik.net/

[HACKERS] Upcoming back-branch update releases

Yup, we're overdue for that, so:

After some discussion among core and the packagers list, we have
tentatively set June 9 as the release date for minor updates of
all supported PG release branches (back to 7.4). As has been the
recent practice, code freeze will occur the preceding Thursday, June 5.

If you've got any bug fixes you've been working on, now is a good time
to get them finished up and sent in...

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[pgsql-es-ayuda] Instalacion desatendida

Saludos al grupo.

Esta vez tengo una pregunta, aunque no meramente de SQL, sino de instalación desatendida.

Como puedo especificar los parámetros para que Postgres se auto instale es decir, que el usuario no tenga que digitar ninguna información sino que yo las establezca.

 

Gracias.

Ing. Eris J. Gómez
Racol Computers, C x A.
Símbolo de calidad en software.
Av. 27 de febrero #37, Villa Progreso
Santiago de los Caballeros, República Dominicana
Tel.: (809) 971-3157, Fax: (809) 582-6636
Email: racolsoftware@hotmail.com