Thursday, June 5, 2008

Re: [pgsql-es-ayuda] Leer ficheros con postgres

On Thu, Jun 5, 2008 at 11:28 AM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:
> Jaime Casanova escribió:
>
>> oops, disculpen el top-posting pero estaba en una ipaq y no veia a
>> donde iba a parar el texto del mensaje que se estaba contestando
>
> Está bueno el trabajo de soporte y capacitación de PG en Ecuador parece,
> que andas probando juguetitos nuevos? ;-)
>

Te dire que me estoy enterando que hay algunas empresas usando
postgres aqui en Ecuador asi que se ven buenas perspectivas... pero la
ipaq me la mando de chile mi hermano (les va bien a los medicos
ecuatorianos en chile :)


--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Guayaquil - Ecuador
Cel. (593) 87171157
--
TIP 3: Si encontraste la respuesta a tu problema, publícala, otros te lo agradecerán

[PATCHES] array_fill function

*** ./src/backend/utils/adt/arrayfuncs.c.orig 2008-06-05 08:16:09.000000000 +0200
--- ./src/backend/utils/adt/arrayfuncs.c 2008-06-06 05:56:56.000000000 +0200
***************
*** 95,100 ****
--- 95,105 ----
int *st, int *endp,
int typlen, bool typbyval, char typalign);
static int array_cmp(FunctionCallInfo fcinfo);
+ static ArrayType *create_array_envelope(int ndims, int *dimv, int *lbv, int nbytes,
+ Oid elmtype, int dataoffset);
+ static ArrayType *array_fill_internal(ArrayType *dims, ArrayType *lbs, Datum value,
+ Oid elmtype, bool isnull,
+ FunctionCallInfo fcinfo);


/*
***************
*** 4314,4316 ****
--- 4319,4590 ----
/* just call the other one -- it can handle both cases */
return generate_subscripts(fcinfo);
}
+
+ /*
+ * array_fill_with_lower_bounds
+ * Create and fill array with defined lower bounds.
+ */
+ Datum
+ array_fill_with_lower_bounds(PG_FUNCTION_ARGS)
+ {
+ ArrayType *dims;
+ ArrayType *lbs;
+ ArrayType *result;
+ Oid elmtype;
+ Datum value;
+ bool isnull;
+
+ if (PG_ARGISNULL(1) || PG_ARGISNULL(2))
+ ereport(ERROR,
+ (errcode(ERRCODE_NULL_VALUE_NOT_ALLOWED),
+ errmsg("dimension array or low bound array cannot be NULL")));
+
+ dims = PG_GETARG_ARRAYTYPE_P(1);
+ lbs = PG_GETARG_ARRAYTYPE_P(2);
+
+ if (!PG_ARGISNULL(0))
+ {
+ value = PG_GETARG_DATUM(0);
+ isnull = false;
+ }
+ else
+ {
+ value = 0;
+ isnull = true;
+ }
+
+ elmtype = get_fn_expr_argtype(fcinfo->flinfo, 0);
+ if (!OidIsValid(elmtype))
+ elog(ERROR, "could not determine data type of input");
+
+ result = array_fill_internal(dims, lbs, value, elmtype, isnull, fcinfo);
+ PG_RETURN_ARRAYTYPE_P(result);
+ }
+
+ /*
+ * array_fill
+ * Create and fill array with default lower bounds.
+ */
+ Datum
+ array_fill(PG_FUNCTION_ARGS)
+ {
+ ArrayType *dims;
+ ArrayType *result;
+ Oid elmtype;
+ Datum value;
+ bool isnull;
+
+ if (PG_ARGISNULL(1))
+ ereport(ERROR,
+ (errcode(ERRCODE_NULL_VALUE_NOT_ALLOWED),
+ errmsg("dimension array or low bound array cannot be NULL")));
+
+ dims = PG_GETARG_ARRAYTYPE_P(1);
+
+ if (!PG_ARGISNULL(0))
+ {
+ value = PG_GETARG_DATUM(0);
+ isnull = false;
+ }
+ else
+ {
+ value = 0;
+ isnull = true;
+ }
+
+ elmtype = get_fn_expr_argtype(fcinfo->flinfo, 0);
+ if (!OidIsValid(elmtype))
+ elog(ERROR, "could not determine data type of input");
+
+ result = array_fill_internal(dims, NULL, value, elmtype, isnull, fcinfo);
+ PG_RETURN_ARRAYTYPE_P(result);
+ }
+
+ static ArrayType *
+ create_array_envelope(int ndims, int *dimv, int *lbsv, int nbytes,
+ Oid elmtype, int dataoffset)
+ {
+ ArrayType *result;
+
+ result = (ArrayType *) palloc0(nbytes);
+ SET_VARSIZE(result, nbytes);
+ result->ndim = ndims;
+ result->dataoffset = dataoffset;
+ result->elemtype = elmtype;
+ memcpy(ARR_DIMS(result), dimv, ndims * sizeof(int));
+ memcpy(ARR_LBOUND(result), lbsv, ndims * sizeof(int));
+
+ return result;
+ }
+
+ static ArrayType *
+ array_fill_internal(ArrayType *dims, ArrayType *lbs, Datum value,
+ Oid elmtype, bool isnull,
+ FunctionCallInfo fcinfo)
+ {
+ ArrayType *result;
+ int *dimv;
+ int *lbsv;
+ int ndims;
+ int nitems;
+ int deflbs[MAXDIM];
+ int16 elmlen;
+ bool elmbyval;
+ char elmalign;
+ ArrayMetaState *my_extra;
+
+ /*
+ * Params checks
+ */
+ if (ARR_NDIM(dims) != 1)
+ ereport(ERROR,
+ (errcode(ERRCODE_ARRAY_SUBSCRIPT_ERROR),
+ errmsg("wrong number of array subscripts"),
+ errhint("dimension array should be one dimensional")));
+
+ if (ARR_LBOUND(dims)[0] != 1)
+ ereport(ERROR,
+ (errcode(ERRCODE_ARRAY_SUBSCRIPT_ERROR),
+ errmsg("wrong range of array_subscripts"),
+ errhint("lbound of dimension array is different than one")));
+
+ if (ARR_HASNULL(dims))
+ ereport(ERROR,
+ (errcode(ERRCODE_NULL_VALUE_NOT_ALLOWED),
+ errmsg("dimension values cannot be null")));
+
+ dimv = (int *) ARR_DATA_PTR(dims);
+ ndims = ARR_DIMS(dims)[0];
+
+ if (ndims < 0) /* we do allow zero-dimension arrays */
+ ereport(ERROR,
+ (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
+ errmsg("invalid number of dimensions: %d", ndims)));
+ if (ndims > MAXDIM)
+ ereport(ERROR,
+ (errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED),
+ errmsg("number of array dimensions (%d) exceeds the maximum allowed (%d)",
+ ndims, MAXDIM)));
+
+ if (lbs != NULL)
+ {
+ if (ARR_NDIM(lbs) != 1)
+ ereport(ERROR,
+ (errcode(ERRCODE_ARRAY_SUBSCRIPT_ERROR),
+ errmsg("wrong number of array subscripts"),
+ errhint("dimension array should be one dimensional")));
+
+ if (ARR_LBOUND(lbs)[0] != 1)
+ ereport(ERROR,
+ (errcode(ERRCODE_ARRAY_SUBSCRIPT_ERROR),
+ errmsg("wrong range of array_subscripts"),
+ errhint("lbound of dimension array is different than one")));
+
+ if (ARR_HASNULL(lbs))
+ ereport(ERROR,
+ (errcode(ERRCODE_NULL_VALUE_NOT_ALLOWED),
+ errmsg("dimension values cannot be null")));
+
+ if (ARR_DIMS(lbs)[0] != ndims)
+ ereport(ERROR,
+ (errcode(ERRCODE_ARRAY_SUBSCRIPT_ERROR),
+ errmsg("wrong number of array_subscripts"),
+ errhint("Low bound array has different size than dimensions array.")));
+
+ lbsv = (int *) ARR_DATA_PTR(lbs);
+ }
+ else
+ {
+ int i;
+
+ for (i = 0; i < MAXDIM; i++)
+ deflbs[i] = 1;
+
+ lbsv = deflbs;
+ }
+
+ /* fast track for empty array */
+ if (ndims == 0)
+ return construct_empty_array(elmtype);
+
+ nitems = ArrayGetNItems(ndims, dimv);
+
+
+ /*
+ * We arrange to look up info about element type only once per series of
+ * calls, assuming the element type doesn't change underneath us.
+ */
+ my_extra = (ArrayMetaState *) fcinfo->flinfo->fn_extra;
+ if (my_extra == NULL)
+ {
+ fcinfo->flinfo->fn_extra = MemoryContextAlloc(fcinfo->flinfo->fn_mcxt,
+ sizeof(ArrayMetaState));
+ my_extra = (ArrayMetaState *) fcinfo->flinfo->fn_extra;
+ my_extra->element_type = InvalidOid;
+ }
+
+ if (my_extra->element_type != elmtype)
+ {
+ /* Get info about element type */
+ get_typlenbyvalalign(elmtype,
+ &my_extra->typlen,
+ &my_extra->typbyval,
+ &my_extra->typalign);
+ my_extra->element_type = elmtype;
+ }
+
+ elmlen = my_extra->typlen;
+ elmbyval = my_extra->typbyval;
+ elmalign = my_extra->typalign;
+
+ /* compute required space */
+ if (!isnull)
+ {
+ int i;
+ char *p;
+ int nbytes;
+ Datum aux_value = value;
+
+ /* make sure data is not toasted */
+ if (elmlen == -1)
+ value = PointerGetDatum(PG_DETOAST_DATUM(value));
+
+ nbytes = att_addlength_datum(0, elmlen, value);
+ nbytes = att_align_nominal(nbytes, elmalign);
+
+ nbytes *= nitems;
+ /* check for overflow of total request */
+ if (!AllocSizeIsValid(nbytes))
+ ereport(ERROR,
+ (errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED),
+ errmsg("array size exceeds the maximum allowed (%d)",
+ (int) MaxAllocSize)));
+
+ nbytes += ARR_OVERHEAD_NONULLS(ndims);
+ result = create_array_envelope(ndims, dimv, lbsv, nbytes,
+ elmtype, 0);
+ p = ARR_DATA_PTR(result);
+ for (i = 0; i < nitems; i++)
+ p += ArrayCastAndSet(value, elmlen, elmbyval, elmalign, p);
+
+ /* cleaning up detoasted copies of datum */
+ if (aux_value != value)
+ pfree((Pointer) value);
+ }
+ else
+ {
+ int nbytes;
+ int dataoffset;
+ bits8 *bitmap;
+
+ dataoffset = ARR_OVERHEAD_WITHNULLS(ndims, nitems);
+ nbytes = dataoffset;
+
+ result = create_array_envelope(ndims, dimv, lbsv, nbytes,
+ elmtype, dataoffset);
+ bitmap = ARR_NULLBITMAP(result);
+ MemSet(bitmap, 0, (nitems + 7) / 8);
+ }
+
+ return result;
+ }
*** ./src/include/catalog/pg_proc.h.orig 2008-06-05 08:39:47.000000000 +0200
--- ./src/include/catalog/pg_proc.h 2008-06-06 05:32:06.000000000 +0200
***************
*** 1014,1021 ****
DESCR("array subscripts generator");
DATA(insert OID = 1192 ( generate_subscripts PGNSP PGUID 12 1 1000 f f t t i 2 23 "2277 23" _null_ _null_ _null_ generate_subscripts_nodir - _null_ _null_ ));
DESCR("array subscripts generator");
!
!
DATA(insert OID = 760 ( smgrin PGNSP PGUID 12 1 0 f f t f s 1 210 "2275" _null_ _null_ _null_ smgrin - _null_ _null_ ));
DESCR("I/O");
DATA(insert OID = 761 ( smgrout PGNSP PGUID 12 1 0 f f t f s 1 2275 "210" _null_ _null_ _null_ smgrout - _null_ _null_ ));
--- 1014,1023 ----
DESCR("array subscripts generator");
DATA(insert OID = 1192 ( generate_subscripts PGNSP PGUID 12 1 1000 f f t t i 2 23 "2277 23" _null_ _null_ _null_ generate_subscripts_nodir - _null_ _null_ ));
DESCR("array subscripts generator");
! DATA(insert OID = 1193 ( array_fill PGNSP PGUID 12 1 0 f f f f i 2 2277 "2283 1007" _null_ _null_ _null_ array_fill - _null_ _null_ ));
! DESCR("array constructor with value");
! DATA(insert OID = 1286 ( array_fill PGNSP PGUID 12 1 0 f f f f i 3 2277 "2283 1007 1007" _null_ _null_ _null_ array_fill_with_lower_bounds - _null_ _null_ ));
! DESCR("array constructor with value");
DATA(insert OID = 760 ( smgrin PGNSP PGUID 12 1 0 f f t f s 1 210 "2275" _null_ _null_ _null_ smgrin - _null_ _null_ ));
DESCR("I/O");
DATA(insert OID = 761 ( smgrout PGNSP PGUID 12 1 0 f f t f s 1 2275 "210" _null_ _null_ _null_ smgrout - _null_ _null_ ));
*** ./src/include/utils/array.h.orig 2008-06-05 08:33:30.000000000 +0200
--- ./src/include/utils/array.h 2008-06-05 08:34:55.000000000 +0200
***************
*** 202,207 ****
--- 202,209 ----
extern Datum array_smaller(PG_FUNCTION_ARGS);
extern Datum generate_subscripts(PG_FUNCTION_ARGS);
extern Datum generate_subscripts_nodir(PG_FUNCTION_ARGS);
+ extern Datum array_fill(PG_FUNCTION_ARGS);
+ extern Datum array_fill_with_lower_bounds(PG_FUNCTION_ARGS);

extern Datum array_ref(ArrayType *array, int nSubscripts, int *indx,
int arraytyplen, int elmlen, bool elmbyval, char elmalign,
*** ./src/test/regress/expected/arrays.out.orig 2008-06-06 06:05:05.000000000 +0200
--- ./src/test/regress/expected/arrays.out 2008-06-06 06:03:32.000000000 +0200
***************
*** 933,935 ****
--- 933,993 ----

drop function unnest1(anyarray);
drop function unnest2(anyarray);
+ select array_fill(null::integer, array[3,3],array[2,2]);
+ array_fill
+ -----------------------------------------------------------------
+ [2:4][2:4]={{NULL,NULL,NULL},{NULL,NULL,NULL},{NULL,NULL,NULL}}
+ (1 row)
+
+ select array_fill(null::integer, array[3,3]);
+ array_fill
+ ------------------------------------------------------
+ {{NULL,NULL,NULL},{NULL,NULL,NULL},{NULL,NULL,NULL}}
+ (1 row)
+
+ select array_fill(null::text, array[3,3],array[2,2]);
+ array_fill
+ -----------------------------------------------------------------
+ [2:4][2:4]={{NULL,NULL,NULL},{NULL,NULL,NULL},{NULL,NULL,NULL}}
+ (1 row)
+
+ select array_fill(null::text, array[3,3]);
+ array_fill
+ ------------------------------------------------------
+ {{NULL,NULL,NULL},{NULL,NULL,NULL},{NULL,NULL,NULL}}
+ (1 row)
+
+ select array_fill(7, array[3,3],array[2,2]);
+ array_fill
+ --------------------------------------
+ [2:4][2:4]={{7,7,7},{7,7,7},{7,7,7}}
+ (1 row)
+
+ select array_fill(7, array[3,3]);
+ array_fill
+ ---------------------------
+ {{7,7,7},{7,7,7},{7,7,7}}
+ (1 row)
+
+ select array_fill('juhu'::text, array[3,3],array[2,2]);
+ array_fill
+ -----------------------------------------------------------------
+ [2:4][2:4]={{juhu,juhu,juhu},{juhu,juhu,juhu},{juhu,juhu,juhu}}
+ (1 row)
+
+ select array_fill('juhu'::text, array[3,3]);
+ array_fill
+ ------------------------------------------------------
+ {{juhu,juhu,juhu},{juhu,juhu,juhu},{juhu,juhu,juhu}}
+ (1 row)
+
+ -- raise exception
+ select array_fill(1, null, array[2,2]);
+ ERROR: dimension array or low bound array cannot be NULL
+ select array_fill(1, array[2,2], null);
+ ERROR: dimension array or low bound array cannot be NULL
+ select array_fill(1, array[3,3], array[1,1,1]);
+ ERROR: wrong number of array_subscripts
+ HINT: Low bound array has different size than dimensions array.
+ select array_fill(1, array[1,2,null]);
+ ERROR: dimension values cannot be null
*** ./src/test/regress/sql/arrays.sql.orig 2008-06-06 05:59:32.000000000 +0200
--- ./src/test/regress/sql/arrays.sql 2008-06-06 06:02:32.000000000 +0200
***************
*** 357,359 ****
--- 357,373 ----

drop function unnest1(anyarray);
drop function unnest2(anyarray);
+
+ select array_fill(null::integer, array[3,3],array[2,2]);
+ select array_fill(null::integer, array[3,3]);
+ select array_fill(null::text, array[3,3],array[2,2]);
+ select array_fill(null::text, array[3,3]);
+ select array_fill(7, array[3,3],array[2,2]);
+ select array_fill(7, array[3,3]);
+ select array_fill('juhu'::text, array[3,3],array[2,2]);
+ select array_fill('juhu'::text, array[3,3]);
+ -- raise exception
+ select array_fill(1, null, array[2,2]);
+ select array_fill(1, array[2,2], null);
+ select array_fill(1, array[3,3], array[1,1,1]);
+ select array_fill(1, array[1,2,null]);
Hello

Proposal: http://archives.postgresql.org/pgsql-hackers/2008-06/msg00057.php

I changed name to array_fill and order of arguments.

postgres=# SELECT array_fill(0, ARRAY[2,3]);
array_fill
-------------------
{{0,0,0},{0,0,0}}
(1 row)

postgres=# SELECT array_fill(0, ARRAY[2,3], ARRAY[1,2]);
array_fill
------------------------------
[1:2][2:4]={{0,0,0},{0,0,0}}
(1 row)

postgres=# SELECT array_fill(0, ARRAY[4], ARRAY[2]);
array_fill
-----------------
[2:5]={0,0,0,0}
(1 row)

postgres=# SELECT array_fill(NULL::int, ARRAY[4]);
array_fill
-----------------------
{NULL,NULL,NULL,NULL}
(1 row)

Regards
Pavel Stehule

Re: [GENERAL] Annoying messages when copy sql code to psql terminal

On Fri, Jun 6, 2008 at 7:58 AM, Merlin Moncure <mmoncure@gmail.com> wrote:
On Tue, May 27, 2008 at 9:24 AM, A B <gentosaker@gmail.com> wrote:
> Whenever I use copy-paste to run code in a terminal window that is
> running psql, and the code contains a row like
>
> IF FOUND THEN
>
> then I get the words
>
> ABORT        CHECKPOINT   COMMIT       DECLARE      EXECUTE

[...]

As others have noted, you have tabs in your sql source.  I'd advise if
possible, not to use the tab character in sql, for this and other
reasons.

Can you please elaborate on other reasons? I have never encountered any _other_ reason!!

And 'using psql' is not reason enough to not indent your SQL code.

Best regards,
--
gurjeet[.singh]@EnterpriseDB.com
singh.gurjeet@{ gmail | hotmail | indiatimes | yahoo }.com

EnterpriseDB http://www.enterprisedb.com

Mail sent from my BlackLaptop device

[COMMITTERS] pgsql: tag 7.4.20

Log Message:
-----------
tag 7.4.20

Tags:
----
REL7_4_STABLE

Modified Files:
--------------
pgsql:
configure (r1.310.2.31 -> r1.310.2.32)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/configure?r1=1.310.2.31&r2=1.310.2.32)
configure.in (r1.301.2.30 -> r1.301.2.31)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/configure.in?r1=1.301.2.30&r2=1.301.2.31)

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

[COMMITTERS] pgsql: tag 8.0.16

Log Message:
-----------
tag 8.0.16

Tags:
----
REL8_0_STABLE

Modified Files:
--------------
pgsql:
configure (r1.424.4.23 -> r1.424.4.24)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/configure?r1=1.424.4.23&r2=1.424.4.24)
configure.in (r1.398.4.24 -> r1.398.4.25)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/configure.in?r1=1.398.4.24&r2=1.398.4.25)

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

[COMMITTERS] pgsql: tag for 8.1.12

Log Message:
-----------

tag for 8.1.12

Tags:
----
REL8_1_STABLE

Modified Files:
--------------
pgsql:
configure (r1.461.2.23 -> r1.461.2.24)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/configure?r1=1.461.2.23&r2=1.461.2.24)
configure.in (r1.431.2.24 -> r1.431.2.25)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/configure.in?r1=1.431.2.24&r2=1.431.2.25)

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

[COMMITTERS] pgsql: tag 8.2.8

Log Message:
-----------

tag 8.2.8

Tags:
----
REL8_2_STABLE

Modified Files:
--------------
pgsql:
configure (r1.523.2.16 -> r1.523.2.17)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/configure?r1=1.523.2.16&r2=1.523.2.17)
configure.in (r1.490.2.17 -> r1.490.2.18)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/configure.in?r1=1.490.2.17&r2=1.490.2.18)

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

[COMMITTERS] pgsql: tag for 8.3.2

Log Message:
-----------

tag for 8.3.2

Tags:
----
REL8_3_STABLE

Modified Files:
--------------
pgsql:
configure (r1.578.2.5 -> r1.578.2.6)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/configure?r1=1.578.2.5&r2=1.578.2.6)
configure.in (r1.546.2.4 -> r1.546.2.5)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/configure.in?r1=1.546.2.4&r2=1.546.2.5)

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

Re: [GENERAL] Extracting data from deprecated MONEY fields

Ken Winter wrote:
> I understand from
> http://www.postgresql.org/docs/8.0/static/datatype-money.html that the
> "money" data type is deprecated.

Money is no longer deprecated in newer releases (specifically 8.3),
although I do think it would be wise to push it to numeric.

I think the way to do it would be to backup the table and edit the table
definition from the file. Make the money a numeric. Then reload the
table from the backup.

Sincerely,

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

[GENERAL] Extracting data from deprecated MONEY fields

I understand from http://www.postgresql.org/docs/8.0/static/datatype-money.html that the “money” data type is deprecated. 

 

So I want to convert the data from my existing “money” columns into new un-deprecated columns, e.g. with type “decimal(10,2)”.  But every SQL command I try tells me I can’t cast or convert “money” data into any other type I have tried, including decimal, numeric, varchar, and text. 

 

Is there any way to do this?

 

~ TIA

~ Ken

Re: [HACKERS] orafce does NOT build with Sun Studio compiler

Hello

2008/6/5 Mayuresh Nirhali <Mayuresh.Nirhali@sun.com>:
> Hello hackers,
>
> During the Oracle migration tutorial by peter at PGCon, I took an action
> item for myself to try orafce on Solaris/OpenSolaris.
> As pg binaries are bundled with Solaris now (using Sun Studio compiler), I
> decided to try out building orafce against the same bundled binaries (with
> USE_PGXS=1).
>
> I see following build error,
> /opt/SUNWspro/SS11/bin/cc -xc99=none -xCC -KPIC -I.
> -I/usr/include/pgsql/server -I/usr/include/pgsql/internal -I/usr/sfw/include
> -I/usr/include/kerberosv5 -c -o pipe.o pipe.c
> "pipe.c", line 149: null dimension: data
> cc: acomp failed for pipe.c
> gmake[1]: *** [pipe.o] Error 2
> gmake[1]: Leaving directory `/builds2/postgres/orafce/orafce'
> *** Error code 2
> make: Fatal error: Command failed for target `orafce/config.status'
> Current working directory /builds2/postgres/orafce
>
> Sun Studio does not like array declarations with null as dimenstion.
> So, In pipe.c we have,
>
> typedef struct
> {
> LWLockId shmem_lock;
> pipe *pipes;
> alert_event *events;
> alert_lock *locks;
> size_t size;
> unsigned int sid;
> char data[]; /* line 149 */
> } sh_memory;
>
> A quick look tells me that this should not be hard to fix, but have not
> prepared any patch as I dont understand the code very well.
> Is it possible to fix this soon ? This will increase the portability and
> would help people use orafce with existing pg binaries on Solaris.
>
> Thanks
> Mayuresh
>
>

I'll fix it soon

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

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

Re: [GENERAL] Annoying messages when copy sql code to psql terminal

On Tue, May 27, 2008 at 9:24 AM, A B <gentosaker@gmail.com> wrote:
> Whenever I use copy-paste to run code in a terminal window that is
> running psql, and the code contains a row like
>
> IF FOUND THEN
>
> then I get the words
>
> ABORT CHECKPOINT COMMIT DECLARE EXECUTE

[...]

As others have noted, you have tabs in your sql source. I'd advise if
possible, not to use the tab character in sql, for this and other
reasons.

merlin

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

[ADMIN] archive_timeout - Is it working??

Hi,

I am currently setting up a warm standby configuration with Postgres 8.3.

Everything seems to be fine but the archive timeout doesnt seem to be

working as expected. The setup is currently in a test environment and I

have set the archive_timeout to be 60sec. The WAL logs however only seem to

be written out when the checkpoint_timeout expires. There is currently very

small amount of database activity in the test environment. But I would have

expected a WAL log be written every 60sec with maybe 1MB of data.

This is what I have set up for testing purposes:

# - Checkpoints -

checkpoint_segments = 3 # in logfile segments, min 1, 16MB

each

checkpoint_timeout = 5min # range 30s-1h

#checkpoint_completion_target = 0.5 # checkpoint target duration, 0.0 -

1.0

#checkpoint_warning = 30s # 0 is off

# - Archiving -

archive_mode = on

archive_command = 'cp -i "%p" /pgbackup/"%f" </dev/null'

archive_timeout = 60s

Is there something I am missing here?

Thanks!

--

-------------------------------------------------

Steve K

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

Re: [COMMITTERS] pgsql: Translation updates.

Alvaro Herrera <alvherre@commandprompt.com> writes:
>> Hmm, there's something weird about this update ... apparently the
>> spanish files were updated but the diff shows up empty. Investigating.

> Well, apparently nobody updated the file in the pgtranslation CVS, so
> it's OK that nothing happened.

Don't scare me like that :-(. This is the first time I've done the
translation commits and I was sure I'd blown it somehow.

> I'm baffled about $PostgreSQL$ being
> unexpanded yet though. Good thing we have a $Id$ that keeps current
> with the pgtranslation repo. Maybe it's $PostgreSQL$ that's causing the
> empty diff to show up.

Hmm, you're right, the es/postgres.po file in the pgtranslation
repository has an unexpanded $PostgreSQL$ tag. Which is unsurprising
since pgfoundry's CVS is probably not set to recognize that tag.

The cp-po script is supposed to ignore that when comparing the files,
but it looks like there's something wrong with its regexp. Don't
quite see what though ... oh, yeah I do: it's assuming there will
be a colon after the keyword. Don't have commit on that repository,
or I'd go fix it ...

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

[GENERAL] Application EventLog: could not write to log file: Bad file descriptor

Using postgresql 8.3 on windows 2003 server.  I keep seeing this message in my system log.   Checking the times, it seems to coincide with a log rollover each time, almost as though the db were trying to log something at precisely the same time as it is closing access to the old file, and before opening the new file.. and so fails to write..     does this make sense? has anyone else seen this? Solutions? Ideas?   I reduced logging, and disabled the debugging plugin (still don't know how that got enabled.. I must have missed something on the install).  Hope that helps....

Any ideas what is causing this error to be logged?
Cheers
Ati

[COMMITTERS] libpqtypes - libpqtypes: fixed memory leak on thread death in

Log Message:
-----------
fixed memory leak on thread death in error.c:tls_free_lasterr()

Modified Files:
--------------
libpqtypes/src:
error.c (r1.4 -> r1.5)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/libpqtypes/libpqtypes/src/error.c.diff?r1=1.4&r2=1.5)

--
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] Overhauling GUCS

On Jun 5, 2008, at 17:53, Greg Smith wrote:

> I was already considering keeping user comments as # while making
> all system-inserted ones #! ; many people are already used to #!
> having a special system-related meaning from its use in UNIX shell
> scripting which makes it easier to remember.

Oooh, yeah. I hadn't even thought of that! I was just looking at
characters on my keyboard and typing them in to see which ones I
thought were most distinctive. This may be part of the reason I
thought that #! was distinctive. :-)

Best,

David

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

[COMMITTERS] libpqtypes - libpqtypes: grammatical error in PQlocalTZInfo.3 man

Log Message:
-----------
grammatical error in PQlocalTZInfo.3 man

Modified Files:
--------------
libpqtypes/docs/man3:
PQlocalTZInfo.3 (r1.2 -> r1.3)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/libpqtypes/libpqtypes/docs/man3/PQlocalTZInfo.3.diff?r1=1.2&r2=1.3)

--
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] Overhauling GUCS

On Thu, 5 Jun 2008, Alvaro Herrera wrote:

> FWIW smb.conf uses ; for one purpose and # for the other.

They're actually combining the way UNIX files use # with how Windows INI
files use ; in a config file context, which I personally find a little
weird.

I was already considering keeping user comments as # while making all
system-inserted ones #! ; many people are already used to #! having a
special system-related meaning from its use in UNIX shell scripting which
makes it easier to remember.

I think the next step to this whole plan is to generate a next-gen
postgresql.conf mock-up showing what each of the outputs from the
pg_generate_conf tool might look like to get feedback on that; it will
make what is planned here a bit easier to understand as well.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD

--
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: Translation updates.

Alvaro Herrera wrote:
> Tom Lane wrote:
>
> > Translation updates.
> >
> > Tags:
> > ----
> > REL8_3_STABLE
>
> Hmm, there's something weird about this update ... apparently the
> spanish files were updated but the diff shows up empty. Investigating.

Well, apparently nobody updated the file in the pgtranslation CVS, so
it's OK that nothing happened. I'm baffled about $PostgreSQL$ being
unexpanded yet though. Good thing we have a $Id$ that keeps current
with the pgtranslation repo. Maybe it's $PostgreSQL$ that's causing the
empty diff to show up.

--
Alvaro Herrera

http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

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

Re: [COMMITTERS] pgsql: Translation updates.

Tom Lane wrote:

> Translation updates.
>
> Tags:
> ----
> REL8_3_STABLE

Hmm, there's something weird about this update ... apparently the
spanish files were updated but the diff shows up empty. Investigating.


--
Alvaro Herrera

http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

--
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] Overhauling GUCS

David E. Wheeler wrote:

> How about a simple rule, such as that machine-generated comments start
> with "##", while user comments start with just "#"? I think that I've
> seen such a rule used before. At any rate, I think that, unless you have
> some sort of line marker for machine-generated comments, there will be no
> way to tell them apart from user comments.

FWIW smb.conf uses ; for one purpose and # for the other.

--
Alvaro Herrera

http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

--
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] Overhauling GUCS

On Jun 5, 2008, at 14:47, Greg Smith wrote:

> This is why there's the emphasis on preserving comments as they pass
> into the GUC structure and back to an output file. This is one of
> the implementation details I haven't fully made up my mind on: how
> to clearly label user comments in the postgresql.conf to distinguish
> them from verbose ones added to the file. I have no intention of
> letting manual user edits go away; what I'm trying to do here (and
> this part is much more me than Josh) is make them more uniform such
> that they can co-exist with machine edits without either stomping on
> the other. Right now doing that is difficult, because it's
> impossible to tell the default comments from the ones the users
> added and the current comment structure bleeds onto the same lines
> as the settings.

How about a simple rule, such as that machine-generated comments start
with "##", while user comments start with just "#"? I think that I've
seen such a rule used before. At any rate, I think that, unless you
have some sort of line marker for machine-generated comments, there
will be no way to tell them apart from user comments.

Other possibilities for machine-comments:

## Machine comment
### Machine comment
#! Machine comment
#@ Machine comment
#$ Machine comment
#^ Machine comment
# Machine comment

I actually kinda like "#!". It's distinctive and unlikely to appear in
a user comment. Anyway, just food for thought.

Best,

David

--
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] "ERROR: operator is not unique" with Custom Data Type

On Jun 5, 2008, at 14:07, Martijn van Oosterhout wrote:

>> I'm sure I'm missing something simple here. How do I make it
>> assignment?
>
> # \h create cast
> Command: CREATE CAST
> Description: define a new cast
> Syntax:
> <snip>
> CREATE CAST (sourcetype AS targettype)
> WITHOUT FUNCTION
> [ AS ASSIGNMENT | AS IMPLICIT ]

I need to read up on the CAST documentation. Thanks.

>> Huh. That's what citext has, too:
>>
>> CREATE CAST (citext AS text) WITHOUT FUNCTION AS IMPLICIT;
>> CREATE CAST (text AS citext) WITHOUT FUNCTION AS IMPLICIT;
>
> And citext probably doesn't work with 8.3? The casting rules wrt text
> have changed...

Yes, that is correct. It builds, but the SQL doesn't all run properly.
I'll be wading through all those failures once I get the basics worked
out with v2.

Thanks,

David


--
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] About dependency reports in DROP RESTRICT

Gregory Stark <stark@enterprisedb.com> writes:
> On the other hand the fact that we don't actually provide an
> exhaustive set of data for that purpose and a) nobody's complained and
> b) it's for basically the same reason that you're suggesting this
> change, ie, that it isn't convenient and isn't important enough to go
> out of our way to build just for that purpose could mean it's a
> reasonable compromise. Are you just worried about the memory and cpu
> cycles or is it actually a lot of code?

Well, the problem is that it uglifies the code quite a lot. The patch
as I've got it now adds a "flags" field to ObjectAddress, which is
unused dead space for about half of the uses of ObjectAddress; to keep
the old behavior we'd need to either add three more half-used fields,
or persuade ObjectAddresses to manage two parallel arrays, neither of
which seems very nice. I'll do it if people want it, but I thought
first I should ask if anyone really cares.

> Incidentally, if it happens to be straightforward (I suspect not :( ) in the
> above example it would be nice to compress out the internal dependencies and
> show just the "view b depends on function a(text)" which would actually make
> sense to a DBA. The intermediate rules going via internal objects (rules)
> they've never heard of make it a lot harder to read.

Actually, I think the patch as I've got it now will behave that way
(though it's not done enough to test yet ...)

>> BTW, it would now be possible to do something like what the shdepend
>> code does, and stuff all these reports into the DETAIL field of a
>> single message, instead of emitting them as separate notices.
>> Any feelings pro or con about that?

> Seems fine either way -- I wonder if one way is more convenient for pgadmin or
> applications? I suspect if so it would be the DETAIL field?

The arguments are all about the same as they were for shdepend messages,
I think. The case to think about is where there are LOTS of
dependencies. Do you want 10000 separate NOTICE messages, or a large,
perhaps truncated DETAIL field? I don't recall for sure, but I think
we made the shdepend code act the way it does because we thought that
was better --- certainly it would've been easy to make it just spit
individual NOTICES like the older pg_depend code does.

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

[COMMITTERS] pgsql: Stamp 7.4.20 (except for configure.in/configure)

Log Message:
-----------
Stamp 7.4.20 (except for configure.in/configure)

Tags:
----
REL7_4_STABLE

Modified Files:
--------------
pgsql/doc:
bug.template (r1.21.6.22 -> r1.21.6.23)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/bug.template?r1=1.21.6.22&r2=1.21.6.23)
pgsql/src/include:
pg_config.h.win32 (r1.11.4.20 -> r1.11.4.21)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/pg_config.h.win32?r1=1.11.4.20&r2=1.11.4.21)
pgsql/src/interfaces/libpq:
libpq.rc (r1.10.4.19 -> r1.10.4.20)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/libpq/libpq.rc?r1=1.10.4.19&r2=1.10.4.20)

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

[COMMITTERS] pgsql: Stamp 8.0.16 (except for configure.in/configure)

Log Message:
-----------
Stamp 8.0.16 (except for configure.in/configure)

Tags:
----
REL8_0_STABLE

Modified Files:
--------------
pgsql/doc:
bug.template (r1.26.4.18 -> r1.26.4.19)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/bug.template?r1=1.26.4.18&r2=1.26.4.19)
pgsql/src/include:
pg_config.h.win32 (r1.21.4.16 -> r1.21.4.17)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/pg_config.h.win32?r1=1.21.4.16&r2=1.21.4.17)
pgsql/src/interfaces/libpq:
libpq.rc.in (r1.2.4.17 -> r1.2.4.18)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/libpq/libpq.rc.in?r1=1.2.4.17&r2=1.2.4.18)
pgsql/src/port:
win32ver.rc (r1.5.4.15 -> r1.5.4.16)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/port/win32ver.rc?r1=1.5.4.15&r2=1.5.4.16)

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

[COMMITTERS] pgsql: Stamp 8.1.12 (except for configure.in/configure)

Log Message:
-----------
Stamp 8.1.12 (except for configure.in/configure)

Tags:
----
REL8_1_STABLE

Modified Files:
--------------
pgsql/doc:
bug.template (r1.34.2.12 -> r1.34.2.13)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/bug.template?r1=1.34.2.12&r2=1.34.2.13)
pgsql/src/include:
pg_config.h.win32 (r1.22.2.14 -> r1.22.2.15)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/pg_config.h.win32?r1=1.22.2.14&r2=1.22.2.15)
pgsql/src/interfaces/libpq:
libpq.rc.in (r1.3.2.11 -> r1.3.2.12)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/libpq/libpq.rc.in?r1=1.3.2.11&r2=1.3.2.12)
pgsql/src/port:
win32ver.rc (r1.6.2.11 -> r1.6.2.12)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/port/win32ver.rc?r1=1.6.2.11&r2=1.6.2.12)

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

[COMMITTERS] pgsql: Stamp 8.2.8 (except for configure.in/configure)

Log Message:
-----------
Stamp 8.2.8 (except for configure.in/configure)

Tags:
----
REL8_2_STABLE

Modified Files:
--------------
pgsql/doc:
bug.template (r1.40.2.7 -> r1.40.2.8)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/bug.template?r1=1.40.2.7&r2=1.40.2.8)
pgsql/src/include:
pg_config.h.win32 (r1.38.2.10 -> r1.38.2.11)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/pg_config.h.win32?r1=1.38.2.10&r2=1.38.2.11)
pgsql/src/interfaces/libpq:
libpq.rc.in (r1.4.2.7 -> r1.4.2.8)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/libpq/libpq.rc.in?r1=1.4.2.7&r2=1.4.2.8)
pgsql/src/port:
win32ver.rc (r1.8.2.7 -> r1.8.2.8)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/port/win32ver.rc?r1=1.8.2.7&r2=1.8.2.8)

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

[COMMITTERS] pgsql: Stamp 8.3.2 (except for configure.in/configure)

Log Message:
-----------
Stamp 8.3.2 (except for configure.in/configure)

Tags:
----
REL8_3_STABLE

Modified Files:
--------------
pgsql/doc:
bug.template (r1.49.2.1 -> r1.49.2.2)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/bug.template?r1=1.49.2.1&r2=1.49.2.2)
pgsql/src/include:
pg_config.h.win32 (r1.50.2.1 -> r1.50.2.2)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/pg_config.h.win32?r1=1.50.2.1&r2=1.50.2.2)
pgsql/src/interfaces/libpq:
libpq.rc.in (r1.7.2.1 -> r1.7.2.2)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/libpq/libpq.rc.in?r1=1.7.2.1&r2=1.7.2.2)
pgsql/src/port:
win32ver.rc (r1.10.2.1 -> r1.10.2.2)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/port/win32ver.rc?r1=1.10.2.1&r2=1.10.2.2)

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

[lapug] June blog

The new blog is up for the month of June.


Also, if you any would like to develop a presentation for July or
August, lease let me know that I can sign you up.

--
Regards,
Richard Broersma Jr.

Visit the Los Angles PostgreSQL Users Group (LAPUG)
http://pugs.postgresql.org/lapug

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

Re: [BUGS] BUG #4198: The bugreport form has an encoding problem

"Tom Lane" <tgl@sss.pgh.pa.us> writes:

> Alvaro Herrera <alvherre@commandprompt.com> writes:
>> It does have a problem, because the email sent does not contain a
>> charset header. It does look OK for me too -- as long as I use a UTF8
>> terminal. The fix is easy, just add this line to the message headers:
>
>> Content-Type: text/plain; charset=utf-8
>
> What happens if someone pastes text into the form that is *not* in UTF-8?

http form submissions include a content-type header too. I don't remember if
PHP (or is it mod_python?) automatically converts incoming strings to the
server encoding or if you're expected to do that yourself? Or if it isn't
being done for us we could just put that encoding in the email headers.

--
Gregory Stark
EnterpriseDB

http://www.enterprisedb.com

Ask me about EnterpriseDB's On-Demand Production Tuning

--
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-advocacy] PostgreSQL derivatives

On Thu, 2008-06-05 at 18:36 -0400, Greg Smith wrote:
> On Thu, 5 Jun 2008, Robert Treat wrote:
> e best terminology to describe the distinction.
>
> > And actually, I don't know of any contributions they have made directly
> > to the community.
>
> Don't make me start one of those discussions about how there are a lot of
> way to directly contribute to the community besides straight code writing.
> If we start it will get Joshua all worked up about that again.

I actually consider the Truviso contribution direct to the community.
Its just that CMD was paid to do it. This isn't really any different
than the work Alvaro did on multi-vacuum workers. CMD didn't "directly"
do the work, we paid a human to do that, Alvaro.

Sincerely,

Joshua D. Drake


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

Re: [pgsql-es-ayuda] Necesito orientacion en servidor postgresql en servidor DELL

Edwin Salguero escribió:

> Miren me compre un servidor con las caracteristicas que abajo se nombran
> pensando que hiba a mejorar muchisimo.. mi sistema pero me encuentro con que
> casi no tenemos nada de mejora hasta puedo aventurarme a decir que en un
> momento fue hasta mas lento que el anterior... que era una maquina normal
> una amd64.. de 3.ghz o sea una chanchita..

Lo principal en un servidor de datos suelen ser los discos (y
secundariamente la cantidad de RAM disponible al motor de datos), no el
procesador.

> Tambien les comento que en un proceso.. para evitar duplicidad bloqueamos
> toda la tabla.. o este proceso no esta bien soportado.. por postgresql.. y
> muchas veces se nos cuelga en este proceso.. bueno conforme a las respuesta
> les voy comentando mas cosas.. de mi error..

Bueno, este puede ser el punto principal del problema, o puede que sea
otra cosa. En realidad, para determinar cual es el punto de lentitud
tendrias que hacer una auditoria. Simplemente ponerle mas hardware y
esperar que ande mucho mejor es ilusorio.

--
Alvaro Herrera

http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
TIP 4: No hagas 'kill -9' a postmaster

Re: [HACKERS] About dependency reports in DROP RESTRICT

"Tom Lane" <tgl@sss.pgh.pa.us> writes:

> Currently, if you do DROP something RESTRICT where there are multiple
> levels of dependencies on the "something", you get reports that might
> look about like this:
>
> NOTICE: x depends on something
...
> So what I'd like to do about it is just use the CASCADE style all the
> time. Thoughts?

Well personally I always react to the notices by adding the CASCADE token but
that's because I'm just testing stuff. If I was working with a real database I
would probably be quite likely to be looking for the minimal fix to break the
dependency chain.

So for example in a situation like this:

postgres=# create function a(text) returns text as 'select $1' language sql;

CREATE FUNCTION
postgres=# select a('foo');
a
-----
foo
(1 row)

postgres=# create view b as select a('foo');
CREATE VIEW

postgres=# create view c as select * from b;
CREATE VIEW

postgres=# drop function a(text);
NOTICE: 00000: rule _RETURN on view b depends on function a(text)
NOTICE: 00000: view b depends on rule _RETURN on view b
NOTICE: 00000: rule _RETURN on view c depends on view b
NOTICE: 00000: view c depends on rule _RETURN on view c
ERROR: 2BP01: cannot drop function a(text) because other objects depend on it

postgres=# create or replace view b as select 'foo'::text as a;
CREATE VIEW

postgres=# drop function a(text);
DROP FUNCTION

postgres=# select * from c;
a
-----
foo
(1 row)

It seems like it's quite relevant to provide the dependency chain to help the
DBA find the point in the chain he wants to intervene.

On the other hand the fact that we don't actually provide an exhaustive set of
data for that purpose and a) nobody's complained and b) it's for basically the
same reason that you're suggesting this change, ie, that it isn't convenient
and isn't important enough to go out of our way to build just for that purpose
could mean it's a reasonable compromise. Are you just worried about the memory
and cpu cycles or is it actually a lot of code?

Incidentally, if it happens to be straightforward (I suspect not :( ) in the
above example it would be nice to compress out the internal dependencies and
show just the "view b depends on function a(text)" which would actually make
sense to a DBA. The intermediate rules going via internal objects (rules)
they've never heard of make it a lot harder to read.

> BTW, it would now be possible to do something like what the shdepend
> code does, and stuff all these reports into the DETAIL field of a
> single message, instead of emitting them as separate notices.
> Any feelings pro or con about that?

Seems fine either way -- I wonder if one way is more convenient for pgadmin or
applications? I suspect if so it would be the DETAIL field?

--
Gregory Stark
EnterpriseDB

http://www.enterprisedb.com

Ask me about EnterpriseDB's On-Demand Production Tuning

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

[COMMITTERS] pgsql: Translation updates.

Log Message:
-----------
Translation updates.

Tags:
----
REL7_4_STABLE

Modified Files:
--------------
pgsql/src/backend/po:
de.po (r1.11.2.7 -> r1.11.2.8)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/po/de.po?r1=1.11.2.7&r2=1.11.2.8)
fr.po (r1.1.2.9 -> r1.1.2.10)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/po/fr.po?r1=1.1.2.9&r2=1.1.2.10)
pgsql/src/bin/pg_controldata/po:
de.po (r1.4.4.1 -> r1.4.4.2)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/pg_controldata/po/de.po?r1=1.4.4.1&r2=1.4.4.2)
fr.po (r1.3.4.1 -> r1.3.4.2)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/pg_controldata/po/fr.po?r1=1.3.4.1&r2=1.3.4.2)
pgsql/src/bin/pg_dump/po:
fr.po (r1.1.2.4 -> r1.1.2.5)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/pg_dump/po/fr.po?r1=1.1.2.4&r2=1.1.2.5)
pgsql/src/bin/pg_resetxlog/po:
fr.po (r1.1.2.1 -> r1.1.2.2)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/pg_resetxlog/po/fr.po?r1=1.1.2.1&r2=1.1.2.2)
pgsql/src/bin/psql/po:
de.po (r1.8.2.6 -> r1.8.2.7)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/psql/po/de.po?r1=1.8.2.6&r2=1.8.2.7)
fr.po (r1.4.2.7 -> r1.4.2.8)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/psql/po/fr.po?r1=1.4.2.7&r2=1.4.2.8)
pgsql/src/bin/scripts/po:
fr.po (r1.1.2.2 -> r1.1.2.3)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/scripts/po/fr.po?r1=1.1.2.2&r2=1.1.2.3)
pgsql/src/interfaces/libpq/po:
fr.po (r1.5.2.3 -> r1.5.2.4)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/libpq/po/fr.po?r1=1.5.2.3&r2=1.5.2.4)

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

[COMMITTERS] pgsql: Translation updates.

Log Message:
-----------
Translation updates.

Tags:
----
REL8_0_STABLE

Modified Files:
--------------
pgsql/src/backend/po:
de.po (r1.19.4.3 -> r1.19.4.4)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/po/de.po?r1=1.19.4.3&r2=1.19.4.4)
fr.po (r1.7.4.7 -> r1.7.4.8)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/po/fr.po?r1=1.7.4.7&r2=1.7.4.8)
pgsql/src/bin/initdb/po:
fr.po (r1.6.4.2 -> r1.6.4.3)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/initdb/po/fr.po?r1=1.6.4.2&r2=1.6.4.3)
pgsql/src/bin/pg_config/po:
fr.po (r1.3.4.2 -> r1.3.4.3)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/pg_config/po/fr.po?r1=1.3.4.2&r2=1.3.4.3)
pgsql/src/bin/pg_controldata/po:
de.po (r1.6 -> r1.6.4.1)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/pg_controldata/po/de.po?r1=1.6&r2=1.6.4.1)
fr.po (r1.8.4.1 -> r1.8.4.2)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/pg_controldata/po/fr.po?r1=1.8.4.1&r2=1.8.4.2)
pgsql/src/bin/pg_ctl/po:
cs.po (r1.2 -> r1.2.4.1)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/pg_ctl/po/cs.po?r1=1.2&r2=1.2.4.1)
fr.po (r1.6.4.4 -> r1.6.4.5)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/pg_ctl/po/fr.po?r1=1.6.4.4&r2=1.6.4.5)
pgsql/src/bin/pg_dump/po:
fr.po (r1.8.4.5 -> r1.8.4.6)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/pg_dump/po/fr.po?r1=1.8.4.5&r2=1.8.4.6)
pgsql/src/bin/pg_resetxlog/po:
fr.po (r1.7.4.1 -> r1.7.4.2)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/pg_resetxlog/po/fr.po?r1=1.7.4.1&r2=1.7.4.2)
pgsql/src/bin/psql/po:
de.po (r1.15.4.2 -> r1.15.4.3)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/psql/po/de.po?r1=1.15.4.2&r2=1.15.4.3)
fr.po (r1.13.4.5 -> r1.13.4.6)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/psql/po/fr.po?r1=1.13.4.5&r2=1.13.4.6)
pgsql/src/bin/scripts/po:
fr.po (r1.7.4.2 -> r1.7.4.3)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/scripts/po/fr.po?r1=1.7.4.2&r2=1.7.4.3)
pgsql/src/interfaces/libpq/po:
fr.po (r1.11.4.2 -> r1.11.4.3)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/libpq/po/fr.po?r1=1.11.4.2&r2=1.11.4.3)

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

[COMMITTERS] pgsql: Translation updates.

Log Message:
-----------
Translation updates.

Tags:
----
REL8_1_STABLE

Modified Files:
--------------
pgsql/src/backend/po:
de.po (r1.21.2.4 -> r1.21.2.5)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/po/de.po?r1=1.21.2.4&r2=1.21.2.5)
fr.po (r1.10.2.5 -> r1.10.2.6)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/po/fr.po?r1=1.10.2.5&r2=1.10.2.6)
tr.po (r1.13.2.2 -> r1.13.2.3)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/po/tr.po?r1=1.13.2.2&r2=1.13.2.3)
pgsql/src/bin/initdb/po:
fr.po (r1.9.2.1 -> r1.9.2.2)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/initdb/po/fr.po?r1=1.9.2.1&r2=1.9.2.2)
tr.po (r1.7.2.1 -> r1.7.2.2)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/initdb/po/tr.po?r1=1.7.2.1&r2=1.7.2.2)
pgsql/src/bin/pg_config/po:
fr.po (r1.6.2.1 -> r1.6.2.2)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/pg_config/po/fr.po?r1=1.6.2.1&r2=1.6.2.2)
pgsql/src/bin/pg_controldata/po:
de.po (r1.9 -> r1.9.2.1)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/pg_controldata/po/de.po?r1=1.9&r2=1.9.2.1)
fr.po (r1.11.2.1 -> r1.11.2.2)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/pg_controldata/po/fr.po?r1=1.11.2.1&r2=1.11.2.2)
tr.po (r1.3.2.1 -> r1.3.2.2)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/pg_controldata/po/tr.po?r1=1.3.2.1&r2=1.3.2.2)
pgsql/src/bin/pg_ctl/po:
cs.po (r1.2 -> r1.2.6.1)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/pg_ctl/po/cs.po?r1=1.2&r2=1.2.6.1)
fr.po (r1.7.2.1 -> r1.7.2.2)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/pg_ctl/po/fr.po?r1=1.7.2.1&r2=1.7.2.2)
tr.po (r1.10.2.1 -> r1.10.2.2)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/pg_ctl/po/tr.po?r1=1.10.2.1&r2=1.10.2.2)
pgsql/src/bin/pg_dump/po:
fr.po (r1.11.2.2 -> r1.11.2.3)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/pg_dump/po/fr.po?r1=1.11.2.2&r2=1.11.2.3)
tr.po (r1.6.2.1 -> r1.6.2.2)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/pg_dump/po/tr.po?r1=1.6.2.1&r2=1.6.2.2)
pgsql/src/bin/pg_resetxlog/po:
fr.po (r1.8.2.1 -> r1.8.2.2)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/pg_resetxlog/po/fr.po?r1=1.8.2.1&r2=1.8.2.2)
tr.po (r1.5.2.1 -> r1.5.2.2)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/pg_resetxlog/po/tr.po?r1=1.5.2.1&r2=1.5.2.2)
pgsql/src/bin/psql/po:
de.po (r1.18.2.2 -> r1.18.2.3)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/psql/po/de.po?r1=1.18.2.2&r2=1.18.2.3)
fr.po (r1.16.2.4 -> r1.16.2.5)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/psql/po/fr.po?r1=1.16.2.4&r2=1.16.2.5)
tr.po (r1.8.2.2 -> r1.8.2.3)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/psql/po/tr.po?r1=1.8.2.2&r2=1.8.2.3)
pgsql/src/bin/scripts/po:
fr.po (r1.10.2.2 -> r1.10.2.3)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/scripts/po/fr.po?r1=1.10.2.2&r2=1.10.2.3)
tr.po (r1.6.2.1 -> r1.6.2.2)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/scripts/po/tr.po?r1=1.6.2.1&r2=1.6.2.2)
pgsql/src/interfaces/libpq/po:
fr.po (r1.14.2.2 -> r1.14.2.3)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/libpq/po/fr.po?r1=1.14.2.2&r2=1.14.2.3)
tr.po (r1.5.2.1 -> r1.5.2.2)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/libpq/po/tr.po?r1=1.5.2.1&r2=1.5.2.2)

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

[COMMITTERS] pgsql: Translation updates.

Log Message:
-----------
Translation updates.

Tags:
----
REL8_2_STABLE

Modified Files:
--------------
pgsql/src/backend/po:
fr.po (r1.13.2.4 -> r1.13.2.5)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/po/fr.po?r1=1.13.2.4&r2=1.13.2.5)
pgsql/src/bin/initdb/po:
fr.po (r1.11.2.3 -> r1.11.2.4)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/initdb/po/fr.po?r1=1.11.2.3&r2=1.11.2.4)
pgsql/src/bin/pg_config/po:
fr.po (r1.7.2.3 -> r1.7.2.4)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/pg_config/po/fr.po?r1=1.7.2.3&r2=1.7.2.4)
pgsql/src/bin/pg_controldata/po:
fr.po (r1.12.2.3 -> r1.12.2.4)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/pg_controldata/po/fr.po?r1=1.12.2.3&r2=1.12.2.4)
pgsql/src/bin/pg_ctl/po:
cs.po (r1.2 -> r1.2.8.1)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/pg_ctl/po/cs.po?r1=1.2&r2=1.2.8.1)
fr.po (r1.9.2.3 -> r1.9.2.4)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/pg_ctl/po/fr.po?r1=1.9.2.3&r2=1.9.2.4)
pgsql/src/bin/pg_dump/po:
fr.po (r1.13.2.3 -> r1.13.2.4)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/pg_dump/po/fr.po?r1=1.13.2.3&r2=1.13.2.4)
pgsql/src/bin/pg_resetxlog/po:
fr.po (r1.9.2.3 -> r1.9.2.4)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/pg_resetxlog/po/fr.po?r1=1.9.2.3&r2=1.9.2.4)
pgsql/src/bin/psql/po:
fr.po (r1.18.2.3 -> r1.18.2.4)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/psql/po/fr.po?r1=1.18.2.3&r2=1.18.2.4)
pgsql/src/bin/scripts/po:
fr.po (r1.12.2.3 -> r1.12.2.4)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/scripts/po/fr.po?r1=1.12.2.3&r2=1.12.2.4)
pgsql/src/interfaces/libpq/po:
fr.po (r1.15.2.3 -> r1.15.2.4)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/libpq/po/fr.po?r1=1.15.2.3&r2=1.15.2.4)

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

[COMMITTERS] pgsql: Translation updates.

Log Message:
-----------
Translation updates.

Tags:
----
REL8_3_STABLE

Modified Files:
--------------
pgsql/src/backend/po:
de.po (r1.29.2.1 -> r1.29.2.2)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/po/de.po?r1=1.29.2.1&r2=1.29.2.2)
es.po (r1.15.2.1 -> r1.15.2.2)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/po/es.po?r1=1.15.2.1&r2=1.15.2.2)
fr.po (r1.18.2.1 -> r1.18.2.2)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/po/fr.po?r1=1.18.2.1&r2=1.18.2.2)
pgsql/src/bin/initdb/po:
fr.po (r1.14 -> r1.14.2.1)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/initdb/po/fr.po?r1=1.14&r2=1.14.2.1)
pgsql/src/bin/pg_config/po:
fr.po (r1.9 -> r1.9.2.1)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/pg_config/po/fr.po?r1=1.9&r2=1.9.2.1)
pgsql/src/bin/pg_controldata/po:
es.po (r1.10.2.1 -> r1.10.2.2)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/pg_controldata/po/es.po?r1=1.10.2.1&r2=1.10.2.2)
fr.po (r1.15 -> r1.15.2.1)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/pg_controldata/po/fr.po?r1=1.15&r2=1.15.2.1)
pgsql/src/bin/pg_ctl/po:
cs.po (r1.2 -> r1.2.10.1)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/pg_ctl/po/cs.po?r1=1.2&r2=1.2.10.1)
fr.po (r1.12 -> r1.12.2.1)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/pg_ctl/po/fr.po?r1=1.12&r2=1.12.2.1)
pgsql/src/bin/pg_dump/po:
fr.po (r1.16 -> r1.16.2.1)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/pg_dump/po/fr.po?r1=1.16&r2=1.16.2.1)
pgsql/src/bin/pg_resetxlog/po:
fr.po (r1.11 -> r1.11.2.1)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/pg_resetxlog/po/fr.po?r1=1.11&r2=1.11.2.1)
pgsql/src/bin/psql/po:
es.po (r1.16.2.1 -> r1.16.2.2)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/psql/po/es.po?r1=1.16.2.1&r2=1.16.2.2)
fr.po (r1.22 -> r1.22.2.1)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/psql/po/fr.po?r1=1.22&r2=1.22.2.1)
pgsql/src/bin/scripts/po:
fr.po (r1.15 -> r1.15.2.1)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/scripts/po/fr.po?r1=1.15&r2=1.15.2.1)
pgsql/src/interfaces/libpq/po:
fr.po (r1.17 -> r1.17.2.1)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/libpq/po/fr.po?r1=1.17&r2=1.17.2.1)

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

Re: [GENERAL] postgres connection problem via python pg DBI

Just solved it. 

 

For others, here is the solution. 

 

setsebool -P httpd_can_network_connect_db 1

 

From: pgsql-general-owner@postgresql.org [mailto:pgsql-general-owner@postgresql.org] On Behalf Of Dan Joo
Sent: Thursday, June 05, 2008 4:18 PM
To: pgsql-general@postgresql.org
Subject: [GENERAL] postgres connection problem via python pg DBI

 

Hi all,

 

I have a problem connecting to postgres via the python pg module ONLY from the cgi-scripts.

 

The command is:

 

db=pg.connect('aqdev','localhost',5432,None,None,'postgres',None)

 

From the commandline the connection works great, but from a cgi-script it barfs with the following message:

 

InternalError: could not create socket: Permission denied

 

Does anyone have any idea how I can get around this issue? 

 

Thanks a bunch!    

Re: [HACKERS] About dependency reports in DROP RESTRICT

Tom Lane wrote:

> So what I'd like to do about it is just use the CASCADE style all the
> time. Thoughts?

It is loss of functionality, but I very much doubt anyone is depending
on it -- it's way too elaborate. +1 on doing the simpler report if it's
too expensive to build the full report.

> BTW, it would now be possible to do something like what the shdepend
> code does, and stuff all these reports into the DETAIL field of a
> single message, instead of emitting them as separate notices.
> Any feelings pro or con about that?

I think it makes more sense to do it that way (considering that they're
really part of the single error message, not independent reports), but
there's the problem that the error report gets too long. So we would
have to send a truncated report to the client and the full report to the
log only. Would people be upset at that?

--
Alvaro Herrera

http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

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

[GENERAL] postgres connection problem via python pg DBI

Hi all,

 

I have a problem connecting to postgres via the python pg module ONLY from the cgi-scripts.

 

The command is:

 

db=pg.connect('aqdev','localhost',5432,None,None,'postgres',None)

 

From the commandline the connection works great, but from a cgi-script it barfs with the following message:

 

InternalError: could not create socket: Permission denied

 

Does anyone have any idea how I can get around this issue? 

 

Thanks a bunch!    

Re: [BUGS] BUG #4198: The bugreport form has an encoding problem

Tom Lane wrote:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
> > It does have a problem, because the email sent does not contain a
> > charset header. It does look OK for me too -- as long as I use a UTF8
> > terminal. The fix is easy, just add this line to the message headers:
>
> > Content-Type: text/plain; charset=utf-8
>
> What happens if someone pastes text into the form that is *not* in UTF-8?

AFAIK the browser sends the encoding along the request and a conversion
takes place somewhere. (If I'm mistaken, then the thing to do is
grab the encoding from the POST request.)

--
Alvaro Herrera

http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

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

Re: [BUGS] BUG #4198: The bugreport form has an encoding problem

Alvaro Herrera <alvherre@commandprompt.com> writes:
> It does have a problem, because the email sent does not contain a
> charset header. It does look OK for me too -- as long as I use a UTF8
> terminal. The fix is easy, just add this line to the message headers:

> Content-Type: text/plain; charset=utf-8

What happens if someone pastes text into the form that is *not* in UTF-8?

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

[GENERAL] pgsql8.3.2 tentative release date

is there a tentative release date (week ... month) for postgres-8.3.2 ?
Thanks!
Vlad

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

[HACKERS] About dependency reports in DROP RESTRICT

Currently, if you do DROP something RESTRICT where there are multiple
levels of dependencies on the "something", you get reports that might
look about like this:

NOTICE: x depends on something
NOTICE: y depends on x
NOTICE: z depends on y

that is, you can trace the chain of reasoning for each deletion.
However, we don't do that in CASCADE mode; you'll just see

NOTICE: drop cascades to x
NOTICE: drop cascades to y
NOTICE: drop cascades to z

I'm working on revising the DROP dependency logic as sketched here:
http://archives.postgresql.org/pgsql-hackers/2008-05/msg00301.php
and I'm realizing that it's going to be quite expensive to maintain the
old NOTICE style for RESTRICT, because we aren't emitting the notices
on-the-fly anymore, but only after we've finished recursing to find all
the objects to delete; we'd have to save about twice as much state to
remember which object was the immediate predecessor of each victim.
And the old behavior was always a bit indeterminate anyway because there
could be multiple dependency paths, and which one got reported as the
deletion cause would be happenstance.

So what I'd like to do about it is just use the CASCADE style all the
time. Thoughts?

BTW, it would now be possible to do something like what the shdepend
code does, and stuff all these reports into the DETAIL field of a
single message, instead of emitting them as separate notices.
Any feelings pro or con about that?

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: [ADMIN] Is it possible to convert WAL's between architectures?

On Thu, Jun 5, 2008 at 4:27 PM, Kevin Grittner
<Kevin.Grittner@wicourts.gov> wrote:
>>>> On Thu, Jun 5, 2008 at 5:18 PM, in message
> <dcc563d10806051518w64a1833w269ecc2b377a1519@mail.gmail.com>, "Scott
> Marlowe"
> <scott.marlowe@gmail.com> wrote:
>> On Thu, Jun 5, 2008 at 9:19 AM, Alvaro Herrera
>> <alvherre@commandprompt.com> wrote:
>>> Marcin Kasperski wrote:
>>>>
>>>> As in the title - is it possible to convert WAL for another
> architecture?
>>>>
>>>> (source database on Linux/i386, contemplating chances to restore
>>>> backup on Linux/amd64)
>>>
>>> No.
>>
>> Technically it really IS possible, but I can't imagine investing the
>> time to be able to do so.
>
> We did this by installing the 32 bit libraries and making a 32 bit
> build which ran under the 64 bit OS.

True. But that would only work on 64/32 split OSes where the chipsets
have a 32 bit compatibility mode. You couldn't do that from i386 to
sparc64 for instance.

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

Re: [GENERAL] full vacuum really slows down query

Thanks for the advice. I will keep playing with it. Can someone here
comment on EnterpriseDB or another companies paid support? I may
consider this to quickly improve my performance.

Scott Marlowe wrote:
> Have you run analyze on the tables? bumped up default stats and re-run analyze?
>
> Best way to send query plans is as attachments btw.
>


--
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] postgres connection problem via python pg DBI

Dan Joo wrote:
> db=pg.connect('aqdev','localhost',5432,None,None,'postgres',None)
>
> From the commandline the connection works great, but from a
> cgi-script it barfs with the following message:
>
> *InternalError*: could not create socket: Permission denied

My (obvious, granted) guess is that you're running it from the command
line as your own user, but the web server is running under another user
who doesn't have the proper permissions (or ident response) to access
the database.

Colin

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