Tuesday, August 5, 2008

Re: [GENERAL] Installation problem ~!

Harshad Pethe wrote:
> I have recently tried to install pgsql on Windows but
> I get the following error consistently !
>
> Error : " psql : recieved invalid response to SSL negotiation ! "
>
> This error is encountered as soon as I try to start psql !

Sounds like an SSL problem.

Check the server certificates and the client certificate if they
match.

Check the "ssl" setting in postgresql.conf.

Check the "sslmode" used in the connection string by the client.

Yours,
Laurenz Albe

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

[COMMITTERS] pgbouncer - pgbouncer: Remove drop_on_error, it was a bad idea.

Log Message:
-----------
Remove drop_on_error, it was a bad idea.

It was a workaround for broken plan-cache in Postgres,
but it's behviour for common case - some queries giving always errors -
is very nasty - it can drop all connections in pool.

Modified Files:
--------------
pgbouncer/doc:
config.txt (r1.12 -> r1.13)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgbouncer/pgbouncer/doc/config.txt.diff?r1=1.12&r2=1.13)
pgbouncer/include:
bouncer.h (r1.18 -> r1.19)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgbouncer/pgbouncer/include/bouncer.h.diff?r1=1.18&r2=1.19)
pgbouncer/src:
main.c (r1.46 -> r1.47)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgbouncer/pgbouncer/src/main.c.diff?r1=1.46&r2=1.47)
server.c (r1.30 -> r1.31)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgbouncer/pgbouncer/src/server.c.diff?r1=1.30&r2=1.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] pgbouncer - pgbouncer: asynctest: check if result comes back ok

Log Message:
-----------
asynctest: check if result comes back ok

Modified Files:
--------------
pgbouncer/test:
asynctest.c (r1.11 -> r1.12)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgbouncer/pgbouncer/test/asynctest.c.diff?r1=1.11&r2=1.12)

--
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] plan invalidation vs stored procedures

On 8/5/08, Merlin Moncure <mmoncure@gmail.com> wrote:
> On Tue, Aug 5, 2008 at 10:12 AM, Martin Pihlak <martin.pihlak@gmail.com> wrote:
> >>> DROP FUNCTION
> >>> create function foo() returns integer as $$ begin return 2; end; $$ language plpgsql;
> >>> CREATE FUNCTION
> >>> execute c1;
> >>> psql:test.sql:11: ERROR: cache lookup failed for function 36555
> >>
> >> This is simply a bad, wrong, stupid way to do it. Why do you not use
> >> CREATE OR REPLACE FUNCTION?
> >>
> >
> > Well, the test case was an illustration. The actual reason for DROP and CREATE is
> > the inability to change function return type. In our case there are plpgsql OUT
> > parameters involved, and there is no other way to add additional OUT parameters
> > without dropping the function first. I'd be glad if this was fixed, but I still
> > think that proper plan invalidation for function changes is needed (inlined
> > functions, ALTER FUNCTION stuff etc.)
>
>
> one workaround is to use a table based custom composite type:
>
> create table foo_output(a int, b text);
>
> create function foo() returns foo_output as ...
>
> alter table foo_output add column c int;
>
> create or replace foo() if necessary. This also works for 'in' variables.
>
> voila! :-) note you can't use standard composite type because there
> is no way to 'alter' it.

Yes. Or require always new name for function.

But the main problem is that if the DROP/CREATE happens, the failure
mode is very nasty - you get permanent error on existing backends.
(Main case I'm talking about is functions calling other functions.)

Some sorta recovery mode would be nice to have, it does not even
need function perfectly. Giving error once and then recover would
be better than requiring manual action from admin.

--
marko

--
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] Initdb problem on debian mips cobalt: Bus error

Glyn Astill wrote:
> http://privatepaste.com/cbY2S4JhtA
>
> Very little difference with the -O0

FWIW: there also seems to be a fairly indepth discussion on the cobalt
related netbsd list from last year about a problem that looks very
similiar (at least to you issue with etch):


http://www.nabble.com/Strange-segmentation-fault-trying-to-run-postgresql-on-current-to9997129.html


Stefan

--
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] recovery via base + WAL replay failure

Finally figured out what was wrong. The data folder had incorrect
permissions after unzipping the base backup. For me, the solution was
unchecking the "Inherit from parent the permission entries that apply to
child objects" option in the Advanced Security Settings dialog for the
data folder & giving the postgres user full control.

Nothing appeared in the log when the database failed to startup b/c the
permissions were wrong. However, an application error did get reported
to Windows which I found using the Event Viewer.

--Rob

--
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] INCREMENTAR EL VALOR DE UNA PARTE DE UNA COLUMNA DE UNA TABALA ESPECIFICA

La situación se resolvio, el problema consistio en que no estaba
afectando la tabla correcta, la sentencia si funcionaba pero como no
estaba afectando la tabla adecuada por lo que con la ayuda de algunos
amigos se logro el objetivo.

Saludos.


Ricardo Granados.

El día 31 de julio de 2008 12:05, Ricardo Granados Tiznado
<ricardo@solargi.net> escribió:
> Pudiera haber problema si el propietario de las bases de datos es
> estro usuario distinto a postgres ?
>
> He tratado de ejecutarlo pero siempre con postgres y no con el dueño
> de la base de datos. esto será importante o postgres como superusuario
> puede afectar cualquier base ?.
>
> saludos.
>
>
> Ricardo Granados.
>
>
>
> El día 25 de junio de 2008 11:34, Antonio Perez <renjin25@yahoo.com> escribió:
>> puedes hacerlo en cualquiera de los dos, en pgadmin3 puedes abrir la ventana
>> de sql y usar el mismo script que usaste en la consola, luego abrir la tabla
>> y revisar los cambios... Una duda por que no hace el cambio a un solo
>> registro y verificas su valor?
>>
>> --- El mié 25-jun-08, Ricardo Granados Tiznado <ricardo@solargi.net>
>> escribió:
>>
>> De: Ricardo Granados Tiznado <ricardo@solargi.net>
>> Asunto: Re: [pgsql-es-ayuda] INCREMENTAR EL VALOR DE UNA PARTE DE UNA
>> COLUMNA DE UNA TABALA ESPECIFICA
>> A: "Alvaro Herrera" <alvherre@commandprompt.com>,
>> pgsql-es-ayuda@postgresql.org
>> Fecha: miércoles, 25 junio, 2008, 1:20 pm
>>
>> Saludos a la lista y gracias por sus comentarios.
>>
>> Una pregunta adicional.
>>
>> ¿Este incremento de valor en la tabla se puede realizar mediante
>> phppgadmin o pgadmin u otro manejador ?
>>
>>
>> Ricardo Granados.
>>
>>
>>
>> El día 25 de junio de 2008 7:44, Alvaro Herrera
>> <alvherre@commandprompt.com> escribió:
>>> Jose Luis Balle escribió:
>>>> Perdón,
>> autocommit desde el lado del servidor no se usa desde la
>> versión
>>>> 7.3.
>>>> De modo que siempre está en on.
>>>> Yo traté de desactivar el autocommit en psql y me dió error.
>>>>
>>>> postgres=# set autocommit to off;
>>>> ERROR: SET AUTOCOMMIT TO OFF is no longer supported
>>>>
>>>> Podes ver el estado desde psql con la sentencia
>>>> show autocommit;
>>>
>>> Autocommit es una propiedad del cliente, no del servidor. (Se
>>> implementó en el servidor hace tiempo, pero después se observó lo
>>> problemático que era y se eliminó).
>>>
>>> En todo caso, esto del autocommit más parece un "red herring"
>> (una pista
>>> falsa). Yo buscaría por el lado de algún cache en el cliente o capa
>>> intermedia.
>>>
>>> --
>>> Alvaro Herrera
>> http://www.CommandPrompt.com/
>>> PostgreSQL Replication,
>> Consulting, Custom Development, 24x7 support
>>>
>>
>>
>>
>> --
>> Ing. Ricardo Granados Tiznado
>> Solar Grupo Industrial, S.A. de C.V.
>> Mazatlan, Sinaloa, México.
>> www,solargi.net
>> --
>> TIP 9: visita nuestro canal de IRC #postgresql-es en irc.freenode.net
>
>
>
> --
> Ing. Ricardo Granados Tiznado
> Solar Grupo Industrial, S.A. de C.V.
> Mazatlan, Sinaloa, México.
> www,solargi.net
>

--
Ing. Ricardo Granados Tiznado
Solar Grupo Industrial, S.A. de C.V.
Mazatlan, Sinaloa, México.
www,solargi.net
--
TIP 8: explain analyze es tu amigo

[GENERAL] Heikkki's Visibility Map patch for postgres 8.4 ?

Hi,
Is Heikki's Visibility Map patch included for the Postgresql 8.4 version
http://archives.postgresql.org/pgsql-hackers/2007-11/msg00142.php

If not whats the status of that patch? Im especially interested in the index-only scan mentioned there!!!

Thanks
Sharmila

Re: [GENERAL] Vacuum Vs Vacuum Full

Its 8.1 and I'm doing a Vacuum using the vacuumdb program.

Thanks Matt, might be time for an upgrade.

> Date: Tue, 5 Aug 2008 11:21:44 -0400
> From: matthew@zeut.net
> To: aklaver@comcast.net
> CC: pgsql-general@postgresql.org; redsmurfau@msn.com
> Subject: Re: [GENERAL] Vacuum Vs Vacuum Full
>
> Adrian Klaver wrote:
> > On Monday 04 August 2008 11:04:00 pm Robert Shaw wrote:
> >> "WARNING: database "mydb" must be vacuumed within 177009986 transactions
> >> HINT: To avoid a database shutdown, execute a full-database VACUUM in
> >> "mydb"."Which is reason I ask the question, is full vacuum backup useful
> >> for anything other than reclaiming disk space.
> >
> > Actually its not asking for a VACUUM FULL but a VACUUM of the full database,
> > instead of selected tables.
> >
> > See below for complete details
> > http://www.postgresql.org/docs/8.3/interactive/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND
>
>
> BTW, what version of PostgreSQL is this? Database-wide vacuum is no
> longer required for XID wraparound issues. I think this was an 8.3
> change but might have happened in 8.2, I don't remember.
>
> Matt


Sell your car for just $40 at CarPoint.com.au It's simple!

Re: [pgadmin-hackers] First public pre-alpha release of GQB (Graphical Query Builder) for pgAdmin

[Please keep list message on-list]

On Tue, Aug 5, 2008 at 1:35 PM, Luis Ochoa <ziul1979@gmail.com> wrote:

>> - The tables are *really* small on OSX. See screenshot 2. Consider
>> using the user-configurable font or SQL font options.
>
> What do you think about allowing user just to change font size?
> In what part of the menu you think this should be add?

That's why I suggested using the existing configurable options. See:

wxFont sysSettings::GetSystemFont();
wxFont sysSettings::GetSQLFont();

The system font is the one used in most controls, the SQL font is used
in ctlSQLBox's (and is usually fixed-width). Both have sensible
defaults on all platforms.

>> - You need to tweak the default views to enlarge the toolbar size on
>> frmQuery to account for the additional button (see frmQuery.h iirc).
>> The button should be placed in a more appropriate place - certainly
>> not after the help button which is always last.
>
> Ok, but after complete all other things [ something like lower priority :)
> ] my list of todo things is really big :'(

Yup, of course.

>> Should look more like:
>>
>> SELECT
>> *
>> FROM
>> pg_class,
>> pg_attribute
>> WHERE
>> pg_attribute.attrelid = pg_class.relname AND
>> pg_class.relname = 'pg_class';
>
> Ok, I believe that the option to generate joins of kind "a.x=b.x" or "a
> join b on (a.x=b.x)" should be added to.

Yes, that syntax will be needed for left/right outer joins etc. - my
comment was more about tidying the general formatting to be more in
line with what we have elsewhere though.

>> - The 'Selected Columns' and 'Columns Criteria' tabs still need to be
>> moved onto the GQB tab (as you already know :-) ).
>
> Yes, but afraid of new bugs on linux/mac when this will be done :'(.... but
> have to be done...

Yes - oh, and that reminds me - the vertical splitter only resizes the
drawing area, not the treeview. I guess this is the splitter bug you
mentioned in you earlier email? You should be able to get that to work
OK - we used to use splitters everywhere before changing to wxAUI.

>> - The column headers on the two tabs are of different heights.
>
> In SQL Editor | GQB tabs?
>
> or in bottom tabs?

Sorry, the column headers of the grids on the bottom tabs.

/D

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

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

Re: [HACKERS] searching bison guru - grouping sets implementation

Pavel Stehule wrote:
> I trying to implement GROUPING SETS feature. But there is basic
> difference between PostgreSQL and ANSI. Pg allows expressions, ANSI
> only column reference.

The conflict seems to arise from the parenthesis, between these two rules:

ordinary_grouping_set:
grouping_column_ref
{
}
*** | '(' grouping_ref_list ')'
{
}
;

and

grouping_column_ref:
a_expr
{}
;

where a_expr can be something like "(foobar)" as well, enclosed in
parenthesis. The grammar is ambiguous for something like
"SELECT ... GROUP BY (foobar)", bison doesn't know if that should be
interpreted as an "'(' grouping_ref_list ')'", whatever that is, or an
a_expr.

I don't know how that should be resolved, or if it's a genuine ambiguity
in the ANSI and PostgreSQL syntax or something that can be fixed with
some Bison magic.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

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

Re: [BUGS] BUG #4339: The postgreSQL service stops abnormally

Hi,

Bhaskar Sirohi wrote:
> ...
> 2008-07-30 15:05:01 EDT LOG: checkpoints are occurring too frequently (28
> seconds apart)
> 2008-07-30 15:05:01 EDT HINT: Consider increasing the configuration
> parameter "checkpoint_segments".
> 2008-07-30 15:13:34 EDT LOG: checkpoints are occurring too frequently (29
> seconds apart)
> 2008-07-30 15:13:34 EDT HINT: Consider increasing the configuration
> parameter "checkpoint_segments".
> 2008-07-30 15:18:50 EDT LOG: checkpoints are occurring too frequently (28
> seconds apart)
> 2008-07-30 15:18:50 EDT HINT: Consider increasing the configuration
> parameter "checkpoint_segments".
> 2008-07-30 15:19:21 EDT LOG: received fast shutdown request

These log lines look like your database is touching lots of tuples,
requiring it to checkpoint frequently. Then it receives a fast shutdown
request - from whoever.

What causes the workload? Did you check memory usage? (And uh.. does
Windows 2003 Server have an OOM Killer or some such?)

Regards

Markus Wanner

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

[HACKERS] searching bison guru - grouping sets implementation

*** ./gram.y.orig 2008-08-05 10:06:05.000000000 +0200
--- ./gram.y 2008-08-05 14:15:16.000000000 +0200
***************
*** 362,367 ****
--- 362,372 ----
%type <node> xml_root_version opt_xml_root_standalone
%type <ival> document_or_content
%type <boolean> xml_whitespace_option
+ %type <list> grouping_element_list
+ %type <node> grouping_element
+ %type <list> grouping_ref_list
+ %type <list> ordinary_grouping_set ordinary_grouping_set_list
+ %type <node> grouping_column_ref


/*
***************
*** 384,390 ****
CLUSTER COALESCE COLLATE COLUMN COMMENT COMMIT
COMMITTED CONCURRENTLY CONFIGURATION CONNECTION CONSTRAINT CONSTRAINTS
CONTENT_P CONTINUE_P CONVERSION_P COPY COST CREATE CREATEDB
! CREATEROLE CREATEUSER CROSS CSV CURRENT_P CURRENT_DATE CURRENT_ROLE
CURRENT_TIME CURRENT_TIMESTAMP CURRENT_USER CURSOR CYCLE

DATABASE DAY_P DEALLOCATE DEC DECIMAL_P DECLARE DEFAULT DEFAULTS
--- 389,395 ----
CLUSTER COALESCE COLLATE COLUMN COMMENT COMMIT
COMMITTED CONCURRENTLY CONFIGURATION CONNECTION CONSTRAINT CONSTRAINTS
CONTENT_P CONTINUE_P CONVERSION_P COPY COST CREATE CREATEDB
! CREATEROLE CREATEUSER CROSS CSV CUBE CURRENT_P CURRENT_DATE CURRENT_ROLE
CURRENT_TIME CURRENT_TIMESTAMP CURRENT_USER CURSOR CYCLE

DATABASE DAY_P DEALLOCATE DEC DECIMAL_P DECLARE DEFAULT DEFAULTS
***************
*** 397,403 ****
FALSE_P FAMILY FETCH FIRST_P FLOAT_P FOR FORCE FOREIGN FORWARD
FREEZE FROM FULL FUNCTION

! GLOBAL GRANT GRANTED GREATEST GROUP_P

HANDLER HAVING HEADER_P HOLD HOUR_P

--- 402,408 ----
FALSE_P FAMILY FETCH FIRST_P FLOAT_P FOR FORCE FOREIGN FORWARD
FREEZE FROM FULL FUNCTION

! GLOBAL GRANT GRANTED GREATEST GROUP_P GROUPING

HANDLER HAVING HEADER_P HOLD HOUR_P

***************
*** 431,440 ****

READ REAL REASSIGN RECHECK REFERENCES REINDEX RELATIVE_P RELEASE RENAME
REPEATABLE REPLACE REPLICA RESET RESTART RESTRICT RETURNING RETURNS REVOKE
! RIGHT ROLE ROLLBACK ROW ROWS RULE

SAVEPOINT SCHEMA SCROLL SEARCH SECOND_P SECURITY SELECT SEQUENCE
! SERIALIZABLE SESSION SESSION_USER SET SETOF SHARE
SHOW SIMILAR SIMPLE SMALLINT SOME STABLE STANDALONE_P START STATEMENT
STATISTICS STDIN STDOUT STORAGE STRICT_P STRIP_P SUBSTRING SUPERUSER_P
SYMMETRIC SYSID SYSTEM_P
--- 436,445 ----

READ REAL REASSIGN RECHECK REFERENCES REINDEX RELATIVE_P RELEASE RENAME
REPEATABLE REPLACE REPLICA RESET RESTART RESTRICT RETURNING RETURNS REVOKE
! RIGHT ROLE ROLLBACK ROLLUP ROW ROWS RULE

SAVEPOINT SCHEMA SCROLL SEARCH SECOND_P SECURITY SELECT SEQUENCE
! SERIALIZABLE SESSION SESSION_USER SET SETOF SETS SHARE
SHOW SIMILAR SIMPLE SMALLINT SOME STABLE STANDALONE_P START STATEMENT
STATISTICS STDIN STDOUT STORAGE STRICT_P STRIP_P SUBSTRING SUPERUSER_P
SYMMETRIC SYSID SYSTEM_P
***************
*** 6470,6479 ****
;

group_clause:
! GROUP_P BY expr_list { $$ = $3; }
| /*EMPTY*/ { $$ = NIL; }
;

having_clause:
HAVING a_expr { $$ = $2; }
| /*EMPTY*/ { $$ = NULL; }
--- 6475,6547 ----
;

group_clause:
! GROUP_P BY grouping_element_list { $$ = NIL; }
| /*EMPTY*/ { $$ = NIL; }
;

+ grouping_element_list:
+ grouping_element
+ {
+ $$ = list_make1($1);
+ }
+ | grouping_element_list ',' grouping_element
+ {
+ $$ = lappend($1, $3);
+ }
+ ;
+
+ grouping_element:
+ ordinary_grouping_set
+ {
+ }
+ | ROLLUP '(' ordinary_grouping_set_list ')'
+ {
+ }
+ | CUBE '(' ordinary_grouping_set_list ')'
+ {
+ }
+ | GROUPING SETS '(' grouping_element_list ')'
+ {
+ }
+ | '(' ')'
+ {
+ }
+ ;
+
+
+ ordinary_grouping_set:
+ grouping_column_ref
+ {
+ }
+ | '(' grouping_ref_list ')'
+ {
+ }
+ ;
+
+ grouping_ref_list:
+ grouping_column_ref
+ {
+ }
+ | grouping_ref_list ',' grouping_column_ref
+ {
+ }
+ ;
+
+ ordinary_grouping_set_list:
+ ordinary_grouping_set
+ {
+ }
+ | ordinary_grouping_set_list ',' ordinary_grouping_set
+ {
+ }
+ ;
+
+ grouping_column_ref:
+ a_expr
+ {}
+ ;
+
+
having_clause:
HAVING a_expr { $$ = $2; }
| /*EMPTY*/ { $$ = NULL; }
***************
*** 9228,9233 ****
--- 9296,9302 ----
| SERIALIZABLE
| SESSION
| SET
+ | SETS
| SHARE
| SHOW
| SIMPLE
***************
*** 9394,9399 ****
--- 9463,9469 ----
| COLUMN
| CONSTRAINT
| CREATE
+ | CUBE
| CURRENT_DATE
| CURRENT_ROLE
| CURRENT_TIME
***************
*** 9413,9418 ****
--- 9483,9489 ----
| FROM
| GRANT
| GROUP_P
+ | GROUPING
| HAVING
| IN_P
| INITIALLY
***************
*** 9436,9441 ****
--- 9507,9513 ----
| PRIMARY
| REFERENCES
| RETURNING
+ | ROLLUP
| SELECT
| SESSION_USER
| SOME
*** ./keywords.c.orig 2008-08-05 10:06:10.000000000 +0200
--- ./keywords.c 2008-08-05 10:15:40.000000000 +0200
***************
*** 114,119 ****
--- 114,120 ----
{"createuser", CREATEUSER, UNRESERVED_KEYWORD},
{"cross", CROSS, TYPE_FUNC_NAME_KEYWORD},
{"csv", CSV, UNRESERVED_KEYWORD},
+ {"cube", CUBE, RESERVED_KEYWORD},
{"current", CURRENT_P, UNRESERVED_KEYWORD},
{"current_date", CURRENT_DATE, RESERVED_KEYWORD},
{"current_role", CURRENT_ROLE, RESERVED_KEYWORD},
***************
*** 180,185 ****
--- 181,187 ----
{"granted", GRANTED, UNRESERVED_KEYWORD},
{"greatest", GREATEST, COL_NAME_KEYWORD},
{"group", GROUP_P, RESERVED_KEYWORD},
+ {"grouping", GROUPING, RESERVED_KEYWORD},
{"handler", HANDLER, UNRESERVED_KEYWORD},
{"having", HAVING, RESERVED_KEYWORD},
{"header", HEADER_P, UNRESERVED_KEYWORD},
***************
*** 321,326 ****
--- 323,329 ----
{"right", RIGHT, TYPE_FUNC_NAME_KEYWORD},
{"role", ROLE, UNRESERVED_KEYWORD},
{"rollback", ROLLBACK, UNRESERVED_KEYWORD},
+ {"rollup", ROLLUP, RESERVED_KEYWORD},
{"row", ROW, COL_NAME_KEYWORD},
{"rows", ROWS, UNRESERVED_KEYWORD},
{"rule", RULE, UNRESERVED_KEYWORD},
***************
*** 337,342 ****
--- 340,346 ----
{"session_user", SESSION_USER, RESERVED_KEYWORD},
{"set", SET, UNRESERVED_KEYWORD},
{"setof", SETOF, COL_NAME_KEYWORD},
+ {"sets", SETS, UNRESERVED_KEYWORD},
{"share", SHARE, UNRESERVED_KEYWORD},
{"show", SHOW, UNRESERVED_KEYWORD},
{"similar", SIMILAR, TYPE_FUNC_NAME_KEYWORD},
Hello

I trying to implement GROUPING SETS feature. But there is basic
difference between PostgreSQL and ANSI. Pg allows expressions, ANSI
only column reference. I have syntax:

group_clause:
GROUP_P BY grouping_element_list
| /*EMPTY*/
;

grouping_element_list:
grouping_element
{
$$ = list_make1($1);
}
| grouping_element_list ',' grouping_element
{
$$ = lappend($1, $3);
}
;

grouping_element:
ordinary_grouping_set
{
}
| ROLLUP '(' ordinary_grouping_set_list ')'
{
}
| CUBE '(' ordinary_grouping_set_list ')'
{
}
| GROUPING SETS '(' grouping_element_list ')'
{
}
| '(' ')'
{
}
;


ordinary_grouping_set:
grouping_column_ref
{
}
| '(' grouping_ref_list ')'
{
}
;

grouping_ref_list:
grouping_column_ref
{
}
| grouping_ref_list ',' grouping_column_ref
{
}
;

ordinary_grouping_set_list:
ordinary_grouping_set
{
}
| ordinary_grouping_set_list ',' ordinary_grouping_set
{
}
;

grouping_column_ref:
columnref
{}
| Iconst
{}
;
;

this works well, but it is ANSI compliant not pg compliant

after change:
grouping_column_ref:
a_expr
{}
;

I getting
[pavel@localhost parser]$ bison gram.y
gram.y: conflicts: 1 shift/reduce, 1 reduce/reduce

so I cannot find any way to remove shift/reduce.

any ideas?

Re: [GENERAL] replication only

In response to Jef Peeraer <jef.peeraer@telenet.be>:
>
> i read about the replication possibilities with postgresql. If i just need
> some replication ( without failover stuff ) to 1 standby server, what
> would be the best option to go with.

Your description of you requirements is very lacking, so much so that
any attempt at suggesting a "best" option would be pointless.

Provide some more information on your requirements and people will be
able to answer intelligently.

--
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/

wmoran@collaborativefusion.com
Phone: 412-422-3463x4023

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

[COMMITTERS] pgsql: Move pgstat.tmp into a temporary directory under $PGDATA named

Log Message:
-----------
Move pgstat.tmp into a temporary directory under $PGDATA named pg_stat_tmp.
This allows the use of a ramdrive (either through mount or symlink) for
the temporary file that's written every half second, which should
reduce I/O.

On server shutdown/startup, the file is written to the old location in
the global directory, to preserve data across restarts.

Bump catversion since the $PGDATA directory layout changed.

Modified Files:
--------------
pgsql/doc/src/sgml:
monitoring.sgml (r1.60 -> r1.61)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/monitoring.sgml?r1=1.60&r2=1.61)
storage.sgml (r1.23 -> r1.24)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/storage.sgml?r1=1.23&r2=1.24)
pgsql/src/bin/initdb:
initdb.c (r1.158 -> r1.159)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/initdb/initdb.c?r1=1.158&r2=1.159)
pgsql/src/include/catalog:
catversion.h (r1.474 -> r1.475)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/catalog/catversion.h?r1=1.474&r2=1.475)
pgsql/src/backend/postmaster:
pgstat.c (r1.177 -> r1.178)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/postmaster/pgstat.c?r1=1.177&r2=1.178)

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

[pgsql-es-ayuda] enlazar(?) tablas mediante un campo en comun (quizas medio OT)

Buenas gente.... espero que no me tiren una silla por lo que voy a preguntar (mis primeros dos mensajes recibidos de la lista me acobardaron un poco :-P )

Una breve reseña:
- Herramientas utilizadas:
a) Postgresql 8.1 sobre Debian Etch.
b) Versión de Postgis correspondiente.
c) Qgis 0.11
d) Grass 6.3 (del svn)
e) gvSIG
f) ARCView (solo para comparativa)

Resulta que tengo un proyecto hecho en ARCView, con sus correspondientes shapes, dbfs, etc.
He montado el motor con la extensión geoespacial, creado las tablas correspondientes, etc.
Luego he migrado los archivos shapes utilizando shp2pgsql (el modulo SPIT del qgis me sigue dando un error) sin problemas.
Teniendo los datos del proyecto migrados, me estaba dedicando a utilizar los cuatro entornos mencionados, cuando noto que no tenia todas las tablas migradas.
Mirando las capas shapes y sus correspondientes dbfs, noto que existe un dbf que no esta relacionado a ningún shape.
Realizando la consulta correspondiente, me indican que esta tabla esta "vinculada" a las otras mediante un campo en común.
Me presentan un par de vías para solucionar esta cuestión, la primera es "desvincular" las tablas (via ARCView) y guardar los shapes nuevamente (con otro nombre) con lo que debería guardar los atributos todos juntos (no funciono). Escribiendo esto se me ocurre que debería haber "unido" la tabla en cuestión con alguna de las otras.... lo voy a probar.
El otro camino era hacerla desde el motor. O sea vincular las tablas usando postgresql.
No soy un DBA, así que quizás mi consulta sea medio zonza.... como se hace esto?

Voy a tratar de explicarme un poco mejor....

Tengo dos tablas: usuarios y mapa

usuarios
id, nombre, dir, geo

mapa
id, loc, manz, parcela, geo

el campo geo es el campo en común.

En Postgres, tengo la tabla mapa con los datos de la capa, y migre (mediante dbf2pos, "toda una aventura") los dbfs "faltantes" a SQL y luego al RDBM.

Lo que me gustaría es que al buscar una ubicación en la capa mapa, el motor mediante el "vinculo" que sería "geo" me traiga el registro desde usuarios.

Espero haber sido algo claro (y soy consciente de mis (aun) limitados conocimientos en postgres, sql y demás....)

Tampoco espero una solución mágica. A veces un "lee esto salame: <link>" es mas útil que un "hace click y dale next next..."

Un abrazo y gracia por su paciencia (si leyeron hasta aquí)

--
Satoru Lucas Shindoi - lucas@dpec.com.ar
SysAdmin GNU/Linux, *NIX
Oficina (06 a 15 hs) 03783 463449 / 425612
ICQ: 95357247 - Gmail: shindoi@gmail.com - lucas@shindoi.com.ar
Messenger: slshindoi@hotmail.com - Yahoo: slshindoi@yahoo.com.ar
--------------------------------------------------------------------------
Sistemas de Informacion - DPEC - https://www.dpec.com.ar/sistemas
Proyectos NEA - www.nea.org.ar
--
TIP 4: No hagas 'kill -9' a postmaster

Re: [HACKERS] Location for pgstat.stat

Tom Lane wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> Attached is a patch that implements this. I went with the option of just
>> storing it in a temporary directory that can be symlinked, and not
>> bothering with a GUC for it. Comments? (documentation updates are also
>> needed, but I'll wait with those until I hear patch comments :-P)
>
> Looks alright in a fast once-over (I didn't test it).

That's what I was after. I tested it myself, obviously :-) Not promising
zero bugs, but I was looking for the comment on the approach. So thanks!


> Two comments:
> Treating the directory as something to create in initdb means you'll
> need to bump catversion when you apply it.

Yeah, i meant to do that as part of the commit. But thanks for the
reminder anyway!

> I'm not sure where you are
> planning to document, but there should at least be a mention in the
> "database physical layout" chapter, since that's supposed to enumerate
> all the subdirectories of $PGDATA.

I'm putting it under "configuring the statistics collector". And I'll
add a directory in that section - had missed that.

//Magnus

--
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] is a 'pairwise' possible / feasible in SQL?

On Mon, Aug 04, 2008 at 05:00:31PM -0400, Rajarshi Guha wrote:
> On Aug 4, 2008, at 4:55 PM, Francisco Reyes wrote:
> > select a.cid as ac, b.cid as bc, count(*) from aic_cid a left
> >outer join
> >aic_cid b on a.cid <>b.cid and a.id = b.id where b.cid is not null
> >group by
> >a.cid, b.cid order by a.cid;
> >
> >Is that what you are looking for?
>
> Thanks a lot - this is very close. Ideally, I'd want unique pairs

You just need to change the "a.cid <> b.cid" equality to something
non-symmetric, i.e. "a.cid < b.cid". I'm also not sure why an outer
join is being used. I've rewritten it to:

SELECT a.cid AS ac, b.cid AS bc, count(*)
FROM aic_cid a, aic_cid b
WHERE a.id = b.id AND a.cid < b.cid
GROUP BY a.cid, b.cid
ORDER BY a.cid, b.cid;

and seem to get similar results.


Sam

--
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] [TOTALMENTE OT] .Net

2008/8/5 Carolina Roman Salgado <rossyr@abulafia.ciencias.uchile.cl>:
> On Tue, 2008-08-05 at 08:49 +0100, Javier Chávez B. wrote:
>> Eh sin comentarios .. ufff que mala leche .. si alguien excepto este
>> caballero me puede echar una mano sin sarcasmos ni estupideces como
>> estas se lo agradeceria .. y ud. sr morales le ruego que sino va a
>> aportar borre el correo ...
>> Gente mala leche en las listas sobra, y hasta el momento esta lista no
>> habia presentado casos de especimenes tan idiotas!!!
>> Hasta luego...
>
> Bueno, bueno, un poco de paciencia a ambos. Es cierto que el señor
> Morales fue un poco bruto, pero la verdad, Javier, es que yo tampoco
> entendí qué quieres. Es evidente que si escribes a la lista buscas
> ayuda, pero un par de ¿? ayudarían a entender cuál es tu pregunta.
>
> --
> Carolina Roman Salgado <rossyr@abulafia.ciencias.uchile.cl>
>
>

Ufff. .. mira efectivamente lei el correo y puede que a simple vista
no se entienda, pero disculpame soy participante de esta lista desde
hace años y es primera vez que se ataca un correo de esta manera, de
echo la politica ha sido siempre de respeto y de ayuda al resto y no
de idioteces como esta, si no date una vuelta en el historial de una
vez que se trato el tema Top - Posting, es por eso que me irrita de
sobremanera aquellos personajes como estos, que en realidad no aportan
en nada. Bueno pero creo que al resto de la lista este tipo de
inconvenientes no le interesan.

Mi pregunta va por el lado .Net por eso puse en mi Topic: Totalmente
OT, para que se entienda que no es una duda PG pero aqui podemos
encontrar profesional de las mas diversas caracteristicas y perfiles.
Ahora mi duda va por lo siguiente, lo que sucede es que hace dias que
estoy tratando de recorrer un formulario de manera automatica, es
decir, pasarle a una funcion un formulario y de acuerdo al tipo de
objeto que contenga poder acceder a las propiedades de un objeto en
particular, de ahi a que pegue mi trozo de codigo.

O sea simplificando,

funcion <algo> <parametro_formulario>
for cont = o hasta <total_objetos_formulario>
if <formulario(indice). tipo> = <campo_texto>
' hacer algo

Se entiende??? sino no se preocupen, no seguire creando polemica.

Desde ya agradecido a todos menos a uno.

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

Re: [HACKERS] Automatic Client Failover

Hi,

Dimitri Fontaine wrote:
> If slave nodes were able to accept connection and redirect them to master, the
> client wouldn't need to care about connecting to master or slave, just to
> connect to a live node.

I've thought about that as well, but think about it this way: to protect
against N failing nodes, you need to forward *every* request through N
living nodes, before actually hitting the node which processes the
query. To me, that sounds like an awful lot of traffic within the
cluster, which can easily be avoided with automatic client failover.

(Why are you stating, that only slaves need to redirect? What is
happening in case of a master failure?)

> So the proposal for Automatic Client Failover becomes much more simpler.

I'm arguing it's the other way around: taking down a node of the cluster
becomes much simpler with ACF, because clients automatically reconnect
to another node themselves. The servers don't need to care.

Regards

Markus Wanner


--
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-es-ayuda] [TOTALMENTE OT] .Net

On Tue, 2008-08-05 at 08:49 +0100, Javier Chávez B. wrote:
> Eh sin comentarios .. ufff que mala leche .. si alguien excepto este
> caballero me puede echar una mano sin sarcasmos ni estupideces como
> estas se lo agradeceria .. y ud. sr morales le ruego que sino va a
> aportar borre el correo ...
> Gente mala leche en las listas sobra, y hasta el momento esta lista no
> habia presentado casos de especimenes tan idiotas!!!
> Hasta luego...

Bueno, bueno, un poco de paciencia a ambos. Es cierto que el señor
Morales fue un poco bruto, pero la verdad, Javier, es que yo tampoco
entendí qué quieres. Es evidente que si escribes a la lista buscas
ayuda, pero un par de ¿? ayudarían a entender cuál es tu pregunta.

--
Carolina Roman Salgado <rossyr@abulafia.ciencias.uchile.cl>

--
TIP 2: puedes desuscribirte de todas las listas simult�neamente
(env�a "unregister TuDirecci�nDeCorreo" a majordomo@postgresql.org)

[HACKERS] small improvement in buffread common

*** pgsql_page_api.7c9eff0cf439/src/backend/storage/buffer/bufmgr.c út srp 5 12:31:44 2008
--- pgsql_page_api/src/backend/storage/buffer/bufmgr.c út srp 5 12:25:01 2008
***************
*** 352,379 ****
if (zeroPage)
MemSet((char *) bufBlock, 0, BLCKSZ);
else
- smgrread(smgr, blockNum, (char *) bufBlock);
- /* check for garbage data */
- if (!PageHeaderIsValid((PageHeader) bufBlock))
{
! if (zero_damaged_pages)
{
! ereport(WARNING,
! (errcode(ERRCODE_DATA_CORRUPTED),
! errmsg("invalid page header in block %u of relation %u/%u/%u; zeroing out page",
! blockNum,
! smgr->smgr_rnode.spcNode,
! smgr->smgr_rnode.dbNode,
! smgr->smgr_rnode.relNode)));
! MemSet((char *) bufBlock, 0, BLCKSZ);
}
- else
- ereport(ERROR,
- (errcode(ERRCODE_DATA_CORRUPTED),
- errmsg("invalid page header in block %u of relation %u/%u/%u",
- blockNum, smgr->smgr_rnode.spcNode,
- smgr->smgr_rnode.dbNode,
- smgr->smgr_rnode.relNode)));
}
}

--- 352,382 ----
if (zeroPage)
MemSet((char *) bufBlock, 0, BLCKSZ);
else
{
! smgrread(smgr, blockNum, (char *) bufBlock);
!
! /* check for garbage data */
! if (!PageHeaderIsValid((Page) bufBlock))
{
! if (zero_damaged_pages)
! {
! ereport(WARNING,
! (errcode(ERRCODE_DATA_CORRUPTED),
! errmsg("invalid page header in block %u of relation %u/%u/%u; zeroing out page",
! blockNum,
! smgr->smgr_rnode.spcNode,
! smgr->smgr_rnode.dbNode,
! smgr->smgr_rnode.relNode)));
! MemSet((char *) bufBlock, 0, BLCKSZ);
! }
! else
! ereport(ERROR,
! (errcode(ERRCODE_DATA_CORRUPTED),
! errmsg("invalid page header in block %u of relation %u/%u/%u",
! blockNum, smgr->smgr_rnode.spcNode,
! smgr->smgr_rnode.dbNode,
! smgr->smgr_rnode.relNode)));
}
}
}

I attach patch which removes useless page header check when page is zeroed. It
is primary used by hash index.

Zdenek

--
Zdenek Kotala Sun Microsystems
Prague, Czech Republic http://sun.com/postgresql

Re: [HACKERS] Automatic Client Failover

Le mardi 05 août 2008, Markus Wanner a écrit :
>  > (Think network partition.)
>
> Uh... well, yeah, of course the servers themselves need to exchange
> their state and make sure they only accept clients if they are up and
> running (as seen by the cluster). That's what the 'view' of a GCS is all
> about. Or STONITH, for that matter.

That's where I'm thinking that some -core smartness would makes this part
simpler, hence the confusion (sorry about that) on the thread.

If slave nodes were able to accept connection and redirect them to master, the
client wouldn't need to care about connecting to master or slave, just to
connect to a live node.

So the proposal for Automatic Client Failover becomes much more simpler.
--
dim

Re: [HACKERS] plan invalidation vs stored procedures

Hello

try version 8.3. There lot of dependencies are solved.

Regards
Pavel Stehule

2008/8/5 Martin Pihlak <martin.pihlak@gmail.com>:
> Howdy,
>
> What is the status of plan invalidation vs stored procedures? From
> the initial design discussion I understand that function change handling
> was postponed to "some time in the future". Is anybody already working
> on that or maybe some ideas of how to implement this?
>
> The business case for the feature is that most of our db logic is inside
> stored procedures and hence use cached plans. Every time a function is
> dropped and recreated we get a storm of "cache lookup failed" errors.
> If we are lucky, the DBA will detect it and apply appropriate workarounds.
> If not ... things get messy.
>
> We are considering of hacking up a proprietary solution to address our
> specific problems (e.g. invalidate every plan on pg_proc changes). But I
> think that this is something that would be useful to a wider audience and
> deserves a more general solution. How about it?
>
> regards,
> Martin
>
>
> --
> 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: [HACKERS] Automatic Client Failover

Hi,

Simon Riggs wrote:
> On Tue, 2008-08-05 at 11:50 +0300, Hannu Krosing wrote:
>> I guess having the title "Automatic Client Failover" suggest to most
>> readers, that you are trying to solve the client side separately from
>> server.
>
> Yes, that's right: separately. Why would anybody presume I meant "and by
> the way you can turn off all other HA measures not mentioned here"? Not
> mentioning a topic means no change or no impact in that area, at least
> on all other hackers threads.

I think the pgbouncer-in-core idea caused some confusion here.

IMO the client failover method is very to what DNS round-robin setups do
for webservers: even if clients might failover 'automatically', you
still have to maintain the server states (which servers do you list in
the DNS?) and care about 'replication' of your site to the webservers.

Regards

Markus Wanner


--
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] Automatic Client Failover

Hi,

Greg Stark wrote:
> a cwnrallu

What is that?

Regards

Markus Wanner

--
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] Automatic Client Failover

Hi,

Tom Lane wrote:
> Huh? The pgpool is on the server, not on the client side.

Not necessarily. Having pgpool on the client side works just as well.

> There is one really bad consequence of the oversimplified failover
> design that Simon proposes, which is that clients might try to fail over
> for reasons other than a primary server failure.

Why is that? It's just fine for a client to (re)connect to another
server due to a fluky connection to the current server. I had something
pretty similar in mind for Postgres-R. (Except that we should definitely
allow to specify more than just a primary and a secondary server.)

> (Think network partition.)

Uh... well, yeah, of course the servers themselves need to exchange
their state and make sure they only accept clients if they are up and
running (as seen by the cluster). That's what the 'view' of a GCS is all
about. Or STONITH, for that matter.

> You really want any such behavior to be managed centrally,
> IMHO.

Controlling that client behavior reliably would involve using multiple
(at least N+1) connections to different servers, so you can control the
client even if N of the servers fail. That's certainly more complex than
what Simon proposed.

Speaking in terms of orthogonality, client failover is orthogonal to the
(cluster-wide) server state management. Which in turn is orthogonal to
how the nodes replicate data. (Modulo some side effects like nodes
lagging behind for async replication...)

Regards

Markus Wanner


--
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] replication only

On 05/08/2008 08:21, Jef Peeraer wrote:

> would be the best option to go with. Slony i presume, although schema
> chanages are not propagated.

Schema changes *are* propagated in Slony, using the EXECUTE SCRIPT
statement:

http://www.slony.info/documentation/stmtddlscript.html

Ray.

------------------------------------------------------------------
Raymond O'Donnell, Director of Music, Galway Cathedral, Ireland
rod@iol.ie
Galway Cathedral Recitals: http://www.galwaycathedral.org/recitals
------------------------------------------------------------------

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

Re: [HACKERS] Automatic Client Failover

On Tue, 2008-08-05 at 11:50 +0300, Hannu Krosing wrote:
> On Tue, 2008-08-05 at 07:52 +0100, Simon Riggs wrote:
> > On Mon, 2008-08-04 at 22:56 -0400, Tom Lane wrote:
> > > Josh Berkus <josh@agliodbs.com> writes:
> > > > I think the proposal was for an extremely simple "works 75% of the time"
> > > > failover solution. While I can see the attraction of that, the
> > > > consequences of having failover *not* work are pretty severe.
> > >
> > > Exactly. The point of failover (or any other HA feature) is to get
> > > several nines worth of reliability. "It usually works" is simply
> > > not playing in the right league.
> >
> > Why would you all presume that I haven't thought about the things you
> > mention? Where did I say "...and this would be the only feature required
> > for full and correct HA failover." The post is specifically about Client
> > Failover, as the title clearly states.
>
> I guess having the title "Automatic Client Failover" suggest to most
> readers, that you are trying to solve the client side separately from
> server.

Yes, that's right: separately. Why would anybody presume I meant "and by
the way you can turn off all other HA measures not mentioned here"? Not
mentioning a topic means no change or no impact in that area, at least
on all other hackers threads.

> > Your comments were illogical anyway, since if it was so bad a technique
> > then it would not work for pgpool either, since it is also a client. If
> > pgpool can do this, why can't another client? Why can't *all* clients?
>
> IIRC pgpool was itself a poor-mans replication solution, so it _is_ the
> point of doing failover.

Agreed.

> > With correctly configured other components the primary will shut down if
> > it is no longer the boss. The client will then be disconnected. If it
> > switches to its secondary connection, we can have an option to read
> > session_replication_role to ensure that this is set to origin.
>
> Probably this should not be an option, but a must.

Perhaps, but some people doing read only queries don't really care which
one they are connected to.

> maybe session_replication_role should be a DBA-defined function, so that
> the same client failover mechanism can be applied to different
> replication solutions, both server-built-in and external.
>
> create function session_replication_role()
> returns enum('master','ro-slave','please-wait-coming-online','...')
> $$
> ...

Maybe, trouble is "please wait coming online" is the message a Hot
Standby would give also. Happy to list out all the states so we can make
this work for everyone.

> > This
> > covers the case where the client has lost connection with primary,
> > though it is still up, yet can reach the standby which has not changed
> > state.
> >
> > DB2, SQLServer and Oracle all provide this feature, BTW. We don't need
> > to follow, but we should do that consciously. I'm comfortable with us
> > deciding not to do it, if that is our considered judgement.
>
> The main argument seemed to be, that it can't be "Automatic Client-ONLY
> Failover."

No argument. Never was. It can't be.

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support


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

[GENERAL] equivalent of "using namespace" with schema

Is there anything simpler than processing the search_path to obtain
the same effect of
using namespace XXX

or if I'd like to execute the same set of operations on the same
"objects" just in a different schema?


--
Ivan Sergio Borgonovo
http://www.webthatworks.it


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

[ADMIN] Restore error

Dear Support!
I speak English not well, sorry.
I use Postgresql 8.3.0 on Win32. So, when I try to restore into database, I have an error such as
 
"2008-08-05 12:07:33 MSD ERROR:  could not load library "C:/Program Files/PostgreSQL/8.3/lib/pldbgapi.dll": unknown error 126
2008-08-05 12:07:33 MSD STATEMENT:  CREATE FUNCTION pldbg_abort_target(session integer) RETURNS SETOF boolean
     AS '$libdir/pldbgapi', 'pldbg_abort_target'
     LANGUAGE c STRICT;"
 
pldbgapi.dll and needed plugins is in their directories. I tried with different options, but...
 
How to restore database?
 
Thank you/
With best regards, Helen

Re: [HACKERS] CommitFest July Over

Hi,

Josh Berkus wrote:
> 2) The number of patches is going to keep increasing with each
> commitfest. As such, the patch list is going to get harder to deal
> with. We now urgently need to start working on CF management software.

Agreed.

> 3) Round Robin Reviewers didn't really work this time, aside from
> champion new reviewer Abhjit. For the most part, RRR who were assigned
> patches did not review them for 2 weeks. Two areas where this concept
> needs to be improved:
> a) we need to assign RRR to patches two days after the start of
> commitfest, not a week later;

Maybe it's just me, but I don't quite understand the concept of RRR. If
I get some spare cycles to review patches, I certainly want to choose
mysqlf which patch I'm going to review. Why is the CF Manager doing any
assignment of patches?

Of course, the reviewers need to coordinate, it doesn't make much sense
for seven people concurrently reviewing the same patch. But shouldn't
the reviewer take care of 'tagging' a patch as being reviewed?

Or do you think it's motivating to get nagged about accepting or
rejecting a patch assignment? For my part, it's been the main reason I
didn't sign up as an RRR: I didn't want to get into that situation. On
the other hand, I must admit that I didn't review any of the outstanding
patches either...

Regards

Markus Wanner

--
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] Initdb problem on debian mips cobalt: Bus error

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

> Gregory Stark <stark@enterprisedb.com> writes:
>> "Tom Lane" <tgl@sss.pgh.pa.us> writes:
>>> (Rather than trying to browbeat configure into doing this, I'd suggest
>>> manually adjusting CFLAGS in src/Makefile.global, then "make clean" and
>>> rebuild.)
>
>> eh? either of these should work fine:
>> ./configure --enable-debug CFLAGS=-O0
>> CFLAGS=-O0 ./configure --enable-debug
>
> The trouble with that approach is that it overrides *everything* that
> configure would normally put into CFLAGS. I only want one thing
> changing, please ... this is confusing enough already.

Eh?

$ ./configure
...
configure: using CFLAGS=-O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv
configure: using CPPFLAGS= -D_GNU_SOURCE
configure: using LDFLAGS= -Wl,--as-needed

$ ./configure CFLAGS=-O0
...
configure: using CFLAGS=-O0 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv
configure: using CPPFLAGS= -D_GNU_SOURCE
configure: using LDFLAGS= -Wl,--as-needed


--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's On-Demand Production Tuning

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

Re: [HACKERS] PL/PythonU

Hannu Krosing wrote:
> On Mon, 2008-08-04 at 13:08 -0400, David Blewett wrote:
>> Hi All:
>>
>> This is an off-shoot of the "Do we really want to migrate plproxy and
>> citext into PG core distribution?" thread.
>>
>> On the way home from PyOhio, I had a conversation with a few people
>> that use Zope a lot. I happened to mention that Postgres doesn't have
>> an untrusted version of pl/python and they were curious as to why.

Personally I'm also constantly mentioning it :-)

>> They directed me to Zope's Restricted Python implementation [1][2]. In
>> doing some research, I found the "Pl/Python -- current maintainer?"
>> [3] thread from 2006. I also found this [4] thread on the python-dev
>> mailing list.
>>
>> Hannu: You had mentioned bringing pl/python up to the level of some of
>> the other pl's. Have you thought any more about pl/pythonu?
>
> My recollection of old times (about python v. 1.6) was that the
> restricted sandboxes had some fatal flaws. I have not followed zope's
> RestrictedPython enough to have an opinion on its safety.

Yes, the old sandbox (restricted execution and bastion) used a
realatively naive approach of basically limiting only imports and iirc.
some file access objects.
That beeing not really bullet proof so these modules have been
removed. This should not be confused with the different approach
restricted python uses and which proofes to be successfull to date.

Regards
Tino

Re: [GENERAL] Initdb problem on debian mips cobalt: Bus error

> > "Tom Lane" <tgl@sss.pgh.pa.us> writes:
> >
> > > (Rather than trying to browbeat configure into
> doing this, I'd suggest
> > > manually adjusting CFLAGS in src/Makefile.global,
> then "make clean" and
> > > rebuild.)
> >
> > eh? either of these should work fine:
> >
> > ./configure --enable-debug CFLAGS=-O0
> > CFLAGS=-O0 ./configure --enable-debug
> >
> > And yes, you have to do make clean. I often forget
> that step :(
>
> I find it easier to create a src/Makefile.custom containing
> the
> following line:
>
> CFLAGS := $(patsubst -O2,-O0,$(CFLAGS))
>
> When I'm done I just rename the file away to keep it
> around for next
> time.

I'm going to keep things simple and just do as Tom says by editing Makefile.global and we'll see what happens. Hopefully at the very lease it'll compile a little quicker with the optimization off.


__________________________________________________________
Not happy with your email address?.
Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html

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

[HACKERS] plan invalidation vs stored procedures

Howdy,

What is the status of plan invalidation vs stored procedures? From
the initial design discussion I understand that function change handling
was postponed to "some time in the future". Is anybody already working
on that or maybe some ideas of how to implement this?

The business case for the feature is that most of our db logic is inside
stored procedures and hence use cached plans. Every time a function is
dropped and recreated we get a storm of "cache lookup failed" errors.
If we are lucky, the DBA will detect it and apply appropriate workarounds.
If not ... things get messy.

We are considering of hacking up a proprietary solution to address our
specific problems (e.g. invalidate every plan on pg_proc changes). But I
think that this is something that would be useful to a wider audience and
deserves a more general solution. How about it?

regards,
Martin


--
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] Automatic Client Failover

On Tue, 2008-08-05 at 07:52 +0100, Simon Riggs wrote:
> On Mon, 2008-08-04 at 22:56 -0400, Tom Lane wrote:
> > Josh Berkus <josh@agliodbs.com> writes:
> > > I think the proposal was for an extremely simple "works 75% of the time"
> > > failover solution. While I can see the attraction of that, the
> > > consequences of having failover *not* work are pretty severe.
> >
> > Exactly. The point of failover (or any other HA feature) is to get
> > several nines worth of reliability. "It usually works" is simply
> > not playing in the right league.
>
> Why would you all presume that I haven't thought about the things you
> mention? Where did I say "...and this would be the only feature required
> for full and correct HA failover." The post is specifically about Client
> Failover, as the title clearly states.

I guess having the title "Automatic Client Failover" suggest to most
readers, that you are trying to solve the client side separately from
server.

> Your comments were illogical anyway, since if it was so bad a technique
> then it would not work for pgpool either, since it is also a client. If
> pgpool can do this, why can't another client? Why can't *all* clients?

IIRC pgpool was itself a poor-mans replication solution, so it _is_ the
point of doing failover.

> With correctly configured other components the primary will shut down if
> it is no longer the boss. The client will then be disconnected. If it
> switches to its secondary connection, we can have an option to read
> session_replication_role to ensure that this is set to origin.

Probably this should not be an option, but a must.

maybe session_replication_role should be a DBA-defined function, so that
the same client failover mechanism can be applied to different
replication solutions, both server-built-in and external.

create function session_replication_role()
returns enum('master','ro-slave','please-wait-coming-online','...')
$$
...


> This
> covers the case where the client has lost connection with primary,
> though it is still up, yet can reach the standby which has not changed
> state.
>
> DB2, SQLServer and Oracle all provide this feature, BTW. We don't need
> to follow, but we should do that consciously. I'm comfortable with us
> deciding not to do it, if that is our considered judgement.

The main argument seemed to be, that it can't be "Automatic Client-ONLY
Failover."

--------------
Hannu


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

Re: [JDBC] macaddr data type and prepared statements

Hi Folks,

OK Think I've got it sorted... At least I'm inserting using a prepared
statement, the following worked fine. Anyone got any suggestions as to
why I shouldn't do it this way, it feels right but its too simple so I'm
being cautious.

Cheers

Steve

----Code----

org.postgresql.util.PGobject MACADDR = new org.postgresql.util.PGobject();
MACADDR.setType("macaddr");
org.postgresql.util.PGobject CIDR = new org.postgresql.util.PGobject();
CIDR.setType("cidr");


try {

Class.forName("org.postgresql.Driver");
conn = DriverManager.getConnection(jdbc_url, jdbc_user,
jdbc_pass);

PreparedStatement stmt = conn.prepareStatement("insert into
log (date, time, mac, network) values (?,?,?,?)");

while (inputLineIterator.hasNext()) {
String[] line = inputLineIterator.next();
if (line == null) {
continue;
}
MACADDR.setValue(line[2]);
CIDR.setValue(line[3]);

stmt.setDate(1, new java.sql.Date(
dfmt.parse(line[0]).getTime()) );
stmt.setTime(2, new java.sql.Time(
tfmt.parse(line[1]).getTime()) );
stmt.setObject(3, MACADDR);
stmt.setString(4, CIDR);
stmt.execute();
}

stmt.close();
}

----Code----

Oliver Jowett wrote:
> Dave Cramer wrote:
>
>> You can extend PGobject to create a PGMacaddr object to get it to
>> work with prepared statements
>
> Or you can put an explicit cast in your insert statement.
>
> -O
>


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

Re: [HACKERS] CommitFest July Over

Robert Treat wrote:
> On Monday 04 August 2008 15:38:35 Josh Berkus wrote:
>> Post-mortem things we've learned about the commitfest are:
>>
>> 1) It's hard to get anything done in June-July.
>>
>
> True... vacations and conferences abound. September should be better in this
> regard I would think.

Um. Looking at my calendar, the second half of september and all of
october is packed solid with conferences. Unlike June, July & August
which were completely empty.

Perhaps it's a US vs EU thing?

(Vacations are July/August though, so that matches)


>> 2) The number of patches is going to keep increasing with each
>> commitfest. As such, the patch list is going to get harder to deal
>> with. We now urgently need to start working on CF management software.
>>
>> 3) Round Robin Reviewers didn't really work this time, aside from
>> champion new reviewer Abhjit. For the most part, RRR who were assigned
>> patches did not review them for 2 weeks. Two areas where this concept
>> needs to be improved:
>> a) we need to assign RRR to patches two days after the start of
>> commitfest, not a week later;
>
> This seems tricky, since you want people to volunteer to review patches
> ideally, will two days be enough? Should people interested in reviewing be
> signing up ahead of time? Looking at the next commitfest, it is going to
> start on a Monday... maybe auto-assigning reviewers on Wednesday is OK.

Um, didn't they already sign up ahead of time? We can't very well hand
out patches to someone who's not interested, can we?


>> b) there needs to be the expectation that RRR will start reviewing or
>> reject the assignment immediately.
>>
>
> I wonder if too much time was spent on patches like the WITH patch, which
> seemed pretty early on it was not ready for commit... thoughts?

I think that happens a lot. Once discussion "takes off" on a patch, it
attracts more people to comment on it, etc.

Plus the whole "hey, i've added a git repo" starts it's own thread :-P


>> 4) We need to work better to train up new reviewers. Some major
>> committer(s) should have worked with Abhjit, Thomas and Martin
>> particularly on getting them to effectively review patches; instead,
>> committers just handled stuff *for* them for the most part, which isn't
>> growing our pool of reviewers.

True.


>> 5) Patch submitters need to understand that patch submission isn't
>> fire-and-forget. They need to check back, and respond to queries from
>> reviewers. Of course, a patch-tracker which automatically notified the
>> submitter would help.
>>
>
> Reviewers should be responding to the email on -hackers that is pointed to by
> the wiki, so patch submitters should be getting notified... right ?

Well, there's really no way to easily do that. I mean, you can't hit
"reply" once you find something in the archives. You'll need to manually
put everybody back in the CC list, so it's much easier to just post to
-hackers.

Thus, I think requiring the submitters to check back on -hackers
regularly is necessary, for now.


>> 6) Overall, I took a low-nag-factor approach to the first time as
>> commitfest manager. This does not seem to have been the best way; I'd
>> suggest for september that the manager make more frequent nags.

Yes, agreed. The manager role was fairly invisible this time around, I
think we should at least try and see what happens.


>> Finally: who wants to be CF Manager for September? I'm willing to do it
>> again, but maybe someone else should get a turn.
>>
>
> Why stop now when you've got the momentum? :-)
>
> Seriously though, I thought we were supposed to have 2 people working as CF
> Managers for each CF... is that not the case?

Umm, IIRC we said one, but we'd rotate.

That said, I think it'd be a good idea if Josh continued across the next
one, given that this one was more or less a "trial run" for the CF
Manager thingy. We can start switching once the role is a bit more
defined. (This is all based on the fact that Josh says he's ok with
doing it, of course :-P)

//Magnus

--
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] Automatic Client Failover

Le mardi 05 août 2008, Tom Lane a écrit :
> Huh? The problem case is that the primary server goes down, which would
> certainly mean that a pgbouncer instance on the same machine goes with
> it. So it seems to me that integrating pgbouncer is 100% backwards.

With all due respect, it seems to me you're missing an important piece of the
scheme here: I certainly failed to explain correctly. Of course, I'm not sure
(by and large) that detailing what I have in mind will answer your concerns,
but still...

What I have in mind is having the pgbouncer listening process both at master
and slave sites. So your clients can already connect to slave for normal
operations, and the listener process simply connects them to the master,
transparently.
When we later provider RO slave, some queries could be processed locally
instead of getting sent to the master.
The point being that the client does not have to care itself whether it's
connecting to a master or a slave, -core knows what it can handle for the
client and handles it (proxying the connection).

Now, that does not solve the client side automatic failover per-se, it's
another way to think about it:
- both master & slave accept connection in any mode
- master & slave are able to "speak" to each other (life link)
- when master knows it's crashing (elog(FATAL)), it can say so to the slave
- when said so, slave can switch to master

It obviously only catches some errors on master, the ones we're able to log
about. So it does nothing on its own for allowing HA in case of master crash.
But...

> Failover that actually works is not something we can provide with
> trivial changes to Postgres. It's really a major project in its
> own right: you need heartbeat detection, STONITH capability,
> IP address redirection, etc. I think we should be recommending
> external failover-management project(s) instead of offering a
> half-baked home-grown solution. Searching freshmeat for "failover"
> finds plenty of potential candidates, but not having used any of
> them I'm not sure which are worth closer investigation.

We have worked here with heartbeat, and automating failover is hard. Not for
technical reasons only, also because:
- current PostgreSQL offers no sync replication, switching means trading or
losing the D in ACID,
- you do not want to lose any commited data.

If 8.4 resolve this, failover implementation will be a lot easier.

What I see my proposal fit is the ability to handle a part of the smartness
in -core directly, so the hard part of the STONITH/failover/switchback could
be implemented in cooperation with -core, not playing tricks against it.

For example, switching back when master gets back online would only means for
the master to tell the slave to now redirect the queries to him as soon as
it's ready --- which still is the hard part, sync back data.

Having clients able to blindly connect to master or any slave and having the
current cluster topology smartness into -core would certainly help here, even
if not fullfilling all HA goals.

Of course, in the case of master hard crash, we still have to get sure it
won't restart on its own, and we have to have an external way to get a chosen
slave become the master.

I'm even envisioning than -core could help STONITH projects with having sth
like the recovery.conf file for the master to restart in not-up-to-date slave
mode. Whether we implement resyncing to the new master in -core or from
external scripts is another concern, but certainly -core could help here
(even if not in 8.4, of course).

I'm still thinking that this proposal has a place in the scheme of an
integrated HA solution and offers interresting bits.

Regards,
--
dim

Re: [pgsql-es-ayuda] conectar desde Java

Gracias German, mi problema es que tengo que hacer una aplicación con un cliente web y un cliente swing, pero aún no comprendo muy bien la parte del mapeo objeto-relacional y JPA, porque aveces se refieren a JPA como una librería y aveces como una especie de standard que se implementa por un framework como Toplink e Hibernate, glassfish utiliza por default toplink y parece que se puede modificar para que utilice hibernate, pero yo no entiendo muy bien algunas cosas:

  1. el jpa sustituye al dbms, quiero decir según la documetacion maneja las transacciones y el acceso a los datos
  2. No he encontrado un ejemplo de como mapear una bdd ya existente, en los ejemplo mencionan que es posible pero más dificil, asi que siempre ponen un ejemplo de como generar la base desde java (que en mi caso no es funcional)
  3. Y por último una pregunta me surge, si se utiliza glassfish-toplink o glassfish-hibernate entonces ¿vale la pena utilizar un dbms como postgres, o es mejor utilizar mysql, ya que de todas formas el jpa va a manejar las transacciones y va a asegurar que sea una base de datos ACID?

Feliz dia

----- Mensaje original ----
De: German Salinas <gs.salinas@gmail.com>
Para: Fernando Aguada <fernandoaguada@yahoo.com.ar>
CC: Edgar Enriquez <edgarpostgres@yahoo.es>; Lista Postgresql <pgsql-es-ayuda@postgresql.org>
Enviado: sábado, 2 de agosto, 2008 16:32:22
Asunto: Re: [pgsql-es-ayuda] conectar desde Java

Estimado,
 
Tengo algo de experiencia con J2EE,Postgresql y AJAX cualquier duda sobre como aplicar esta tecnologia me escribes a mi correo gs.salinas@gmail.com y si puedo ayudarte lo hare con todo gusto.
 
Hago extensiva esta invitacion a cualquier hermano del OPEN SOURCE..
 
Un saludo,
German Salinas

El 2 de agosto de 2008 7:29, Fernando Aguada<fernandoaguada@yahoo.com.ar>escribió:
Hola
      JPA, Hibernate son framework de persistencia, lo que hacen es proveer una capa que conecta con un motor de bases de datos cualquiera, de esta manera, podrias cambiar de un motor de datos a otro sin que te veas en la necesidad de cambiar nada en tu aplicacion.
Al menos asi lo entiendo yo.

Saludos Cordiales.


----- Original Message ----- From: "Edgar Enriquez" <edgarpostgres@yahoo.es>
To: "Marco Castillo" <mabcastillo@gmail.com>; "lista postgres" <pgsql-es-ayuda@postgresql.org>
Sent: Saturday, August 02, 2008 6:39 AM
Subject: Re: [pgsql-es-ayuda] conectar desde Java





yo también nececito crear una aplicación java para conectarme a una BDD postgres, actualmente tengo todo sobre JDBC, pero para utilizar crear un servidor me digeron que nececito instalar Glassfish y crear allí las conexiones pero luego se habla de JPA, Hibernate y toplink (que aparentementa hacen lo mismo) pero al final la conexión la termina haciento el JDBC de postgres, alguien sabe cual es la diferencia? porque además parece que glassfish maneja la concurrencia (algo que tradicionalmente se hace en Postgres)

Saludos a todos y gracia por sus respuestas



----- Mensaje original ----
De: Marco Castillo <mabcastillo@gmail.com>
Para: "pgsql-es-ayuda@postgresql.org" <pgsql-es-ayuda@postgresql.org>
Enviado: viernes, 1 de agosto, 2008 21:04:54
Asunto: Re: [pgsql-es-ayuda] conectar desde Java


Pues la idea del foro es aprender y ayudarnos mutuamente (mi percepción personal). Aca habemos varios que trabajamos en Java y en PostgreSQL. Haz tus preguntas aca y te echamos una mano.

Saludos

Marco


2008/8/1 Fabio Arias <fharias@gmail.com>

Cualquier cosa que necesitas sobre java+postgresql me escribes con mucho gusto te ayudaré

Bye


El 1 de agosto de 2008 9:50, Gabriel Ferro<gabrielrferro@yahoo.com.ar>escribió:

ok, mil gracias a todo. logre hacerlo, aunque me cuesta, considerando que no se nada de java y soy de la vieja escuela donde objetos y clases no existian.
¿alguien conoce una lista buena de java+postgre en español?


________________________________

¡Buscá desde tu celular!
Yahoo! oneSEARCH ahora está en Claro
http://ar.mobile.yahoo.com/onesearch


--
Fabio Hernando Arias Vera
Cel. 314 411 7776


    ______________________________________________
Enviado desde Correo Yahoo! La bandeja de entrada más inteligente.
--
TIP 3: Si encontraste la respuesta a tu problema, publícala, otros te lo agradecerán




Enviado desde Correo Yahoo!
La bandeja de entrada más inteligente.

Re: [HACKERS] Automatic Client Failover

Greg

On 5-Aug-08, at 12:15 AM, "Tom Lane" <tgl@sss.pgh.pa.us> wrote:
>
> There is one really bad consequence of the oversimplified failover
> design that Simon proposes, which is that clients might try to fail
> over
> for reasons other than a primary server failure. (Think network
> partition.) You really want any such behavior to be managed
> centrally,
> IMHO.

The alternative to a cwnrallu managed failover system is one based
on a quorum system. At first glance it seems to me that would fit our
use case better. But the point remains that we would be better off
adopting a complete system than trying to reinvent one.

--
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-es-ayuda] [TOTALMENTE OT] .Net

2008/8/4 <mmorales@opencorp.cl>:
>> Estimados:
>
> Hola.
>
>> Tengo algo que le estoy dando vueltas hace dias, resulta que por X
>> motivo tengo un formulario que limpiar y dejar los objetos invisibles,
>> abusando un poco de la lista alguien ha echo algo asi.. me refiiero a
>> algo asi :
>>
>> Dim Li_count As Integer
>> Li_count = 0
>> For Each ctl As Object In Me.Form.Controls
>> If Me.Form.GetType.ToString = "System.Windows.Forms.TextBox"
>> Then
>> Me.Form.Controls(Li_count).Visible = False
>> End If
>> Li_count = Li_count + 1
>> Next
>>
>> O sea recorrer el formulario y si es de tipo Texbox dejarlo
>> invisible.. puede ser un C# o Vb.net porque tengo un conversor ... si
>> ha alguien le interesa le puedo dar la dire de eso a su correo
>> personal...
>> Desde ya agradecido!!...
>
> Estoy seguro que el castellano provee de la herramientas necesarias
> para que se logre una buena comunicación.
>
> NO TE ENTIENDO NADA. ¿ Tratas de hacerte el amable y quieres compartir con
> nosotros una solución a algún problema ?. ¿ Tienes algún problema con .NET
> ? .. ¿ No sabes si tienes correo electrónico ? ... ¿ O seré yo que no se
> leer castellano. ?
>
> Saludos,
>
> -- Mauro
>
>

Eh sin comentarios .. ufff que mala leche .. si alguien excepto este
caballero me puede echar una mano sin sarcasmos ni estupideces como
estas se lo agradeceria .. y ud. sr morales le ruego que sino va a
aportar borre el correo ...
Gente mala leche en las listas sobra, y hasta el momento esta lista no
habia presentado casos de especimenes tan idiotas!!!
Hasta luego...

J.

--
----------------------
Slds.
jchavez
linux User #397972 on http://counter.li.org/
--
TIP 9: visita nuestro canal de IRC #postgresql-es en irc.freenode.net

Re: [HACKERS] Reliability of CURRVAL in a RULE

Nick wrote:
> Is the use of CURRVAL in this example reliable in heavy use?

Nick - the hackers list is for people interested in working on the
code-base of PostgreSQL itself. This would have been better on the
general or sql lists.

> CREATE RULE add_email AS ON INSERT TO users WHERE (NEW.email IS NULL)
> DO INSERT INTO users_with_email (id) VALUES (CURRVAL('users_id_seq'));

Short answer no. Rules are like macros and you can end up with
unexpected multiple evaluations and strange order of execution. See the
mailing list archives for details and try inserting multiple users in
one go to see an example of a problem.

--
Richard Huxton
Archonet Ltd

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

[GENERAL] replication only

i read about the replication possibilities with postgresql. If i just need
some replication ( without failover stuff ) to 1 standby server, what
would be the best option to go with. Slony i presume, although schema
chanages are not propagated.

thanks


jef peeraer

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

[GENERAL] mailing list/newsgroup disconnect

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

There seems to be a disconnect between the mailing list and the
newsgroup right now. I received a bunch of replies via email that did
not show up in the newsgroup. (I did not receive any messages that were
sent to the mailing list and not to me personally).

Is there someone I should mention this to or does he already know?

Sim
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkiX/VoACgkQjDX6szCBa+ppsACdHVwJB6oGkX8+xR5U0YYPL08W
UI8AoMq8Frkq/dl/Z860ej/n+kFWuKQV
=xNYA
-----END PGP SIGNATURE-----

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