Wednesday, July 2, 2008

Re: [pgsql-es-ayuda] Re[2]: [pgsql-es-ayuda] Recomendación para desarrollar aplicación que necesita datos de dos bases distintas

José Luis:

Gracias .... Ahhhhh ya cojo el thread ... yo haría una salva de la BD o
de la Tabla que me interesa y la trasporto al otro servidor.

O se me ocurre pasarlo todo a una nueva versión de postgres y comenzar
las nuevas cosa allí junto a toda la data anterior.

Bueno es tan solo una idea de reunificar y reutilizar la información de
la data.

Gilberto.
El mié, 02-07-2008 a las 16:11 -0300, Jose Luis Balle escribió:
> Si las conozco, muchas gracias Gilberto.
> No obstante desde el punto de vista de la documentación, orden,
> estructura, conformación de la base de datos, a "mi" manera de ver,
> cada cosa iría en un esquema que indique de que se trata, en el
> público solo aquellas tablas genericas, compartidas por cualquier
> aplicación, ej: paises, provincias, tipo_de_documento, etc. pero solo
> a nivel teorico, es como un grano en la frente, en la práctica las
> tablas pueden estar todas en el esquema público con un prefijo en el
> nombre y ya. Pero para eso están los esquemas.
> De todas formas, no es el punto del thread que inició Laura.
> Resumiendo, Laura:
> - Puedes usar un schema "encuestas" en la base de datos "academicos".
> - Puedes usar dblink en la base de datos "encuestas" para crear una
> vista a las tablas de la base de datos "academicos", aunque esta es
> desaconsejada por gente del foro que tiene muchas experiencia como
> Alvaro.
> - Puedes crear las tablas en la base de datos "estadísticas" y correr
> un script de sincronización. (menos recomendable aún)
> Saludos.
> José Luis
>
> El día 2 de julio de 2008 15:08, Gilberto Castillo Martínez
> <gilberto.castillo@etecsa.cu> escribió:
> > José Luis:
> >
> > Te dejo unas notas de como trabajar con esquemas si interferir en las
> > aplicaciones... espero te ayude.
> >
> > Trabajando con esquemas.
> > En ocasiones queremos llamar una tabla que está en un esquema
> > determinado, pero sin poner el prefijo del esquema por ejemplo: select *
> > from esquema1.tabla1; sino poner solamente select * from tabla1, para
> > esto se puede decirle al usuario logeado el orden en que va a buscar en
> > los esquemas:
> >
> > SET search_path TO esquema1,public;
> >
> > Para hacerlo permanente ponemos
> >
> > ALTER USER test SET search_path TO esquema1,public;
> >
> > Saludos,
> > Gilberto.
> >
> > El mié, 02-07-2008 a las 12:31 -0300, Jose Luis Balle escribió:
> >> Desordenar en el sentido de que la base de datos original no contempla
> >> esquemas, es como si a la base de datos recursos humanos que reside en
> >> el esquema publico le pongo un esquema inspecciones para poder tomar
> >> los datos del personal.
> >> Por ahí me cuesta tomar el esquema público como un esquema más, no se,
> >> pero para utilizar esquemas y que quede prolijo (algo muy subjetivo)
> >> el diseño debería haber arrancado con esquemas, si ya tiene todo
> >> armado en el público cuando las tablas no son de acceso publico... en
> >> fin, algo muy subjetivo y tal vez no viene al caso.
> >>
> >> El día 2 de julio de 2008 12:02, Alvaro Herrera
> >> <alvherre@commandprompt.com> escribió:
> >> > Jose Luis Balle escribió:
> >> >> Alvaro, se que es incomodo el dblink, pero se justifica desordenar el
> >> >> esquema de la base de datos de los alumnos solo para poder tomar
> >> >> identificadores aislados como materia, alumno,etc?
> >> >
> >> > ¿Desordenar el esquema en qué sentido?
> >> >
> >> >> Si luego quisieran explotar la información de estadísticas sin afectar
> >> >> el rendimiento de academicos...
> >> >
> >> > En ese caso lo ideal es sacar los datos a una réplica y ejecutar los
> >> > procesos de reporte en la réplica.
> >> >
> >> >> Con los esquemas quedaría la base de datos "academicos" con un esquema
> >> >> "estadisticas" dentro, entonces en el esquema público tendría todas
> >> >> las tablas de academicos que utilizas actualmente y en el esquema
> >> >> "estadísticas" solo las que va a utilizar ahora.
> >> >
> >> > No veo en qué sentido eso sea un problema.
> >> >
> >> > --
> >> > Alvaro Herrera

http://www.CommandPrompt.com/
> >> > The PostgreSQL Company - Command Prompt, Inc.
> >> >
> >>
> >>
> >>
> >
> >
>
>
>
> --
> Informático:
> Persona falta de recursos que, partiendo de premisas falsas y de
> especificaciones inconsistentes e incompletas, dirigido por
> incompetentes y utilizando herramientas que no funcionan es capaz de
> iniciar un proyecto de dudoso éxito realizando una obra de arte que
> ,por supuesto, es cara y no tiene otro fin que dar prestigio a la
> empresa que ha contratado sus servicios.
> http://islamanzana.es/desarrollo-de-software/definicion-de-informatico
> --
> TIP 3: Si encontraste la respuesta a tu problema, publícala, otros te lo agradecerán
>

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

Re: [ADMIN] Postgres windows service shutdowns after start

Wow, thanks)

Igor Neyman wrote:
>
> "stats_start_collector" is an obsolete parameter in 8.3, that's why PG
> wouldn't start with it.
>
> Igor
>
>
>
>

--
View this message in context: http://www.nabble.com/Postgres-windows-service-shutdowns-after-start-tp18244024p18244955.html
Sent from the PostgreSQL - admin mailing list archive at Nabble.com.


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

[lapug] July's LAPUG meeting

Would anyone disagree to having the next Lapug meeting at the City of
Garden Groves Youth Center?

--
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: [pgsql-es-ayuda] no repetir nombre

Hola.

Si la idea es hacer un trabajo para tratar de contrarestar las inconsistencias en tu BD, y se tiene el problema de que las personas no portan su cedula, ni se saben de memoria el numero yo personalmente solucionaria el problema inclullendo en la BD algo que ellos siempre tienen con sigo y en la mayoria de los casos serian los dedos (en algunas personas como ami, nos hacen falta algunos), registrar con un huellador la huella del pasiente en la BD y asociarlo a un registro decliente que contenga preferiblemente los apellidos y nombres por separado (por ejemplo primer_nombre, segundo_nombre, primer_apellido, segundo_apellido) y en el momento de implementar esta solución, rellenar el formulario lo mas completamente posible y con inf real.

Asi creo yo que seria lo mas acertado posible en este caso tan particular de tu ciudad.
> > Date: Wed, 2 Jul 2008 12:48:36 -0400
> > From: alvherre@commandprompt.com
> > To: josefermin54@hotmail.com
> > CC: jaleman@layconsa.com.pe; pgsql-es-ayuda@postgresql.org
> > Subject: Re: [pgsql-es-ayuda] no repetir nombre
> >
> > José Fermín Francisco Ferreras escribió:
> > > Gracias a los q han contestado, resulta q aquí (República
> Dominicana)
> > > cada persona tiene su Cédula d identificación personal, pero, aquí
> en
> > > mi país se da con mucha frecuencia q la gente no lleva la cédula
> > > consigo y mucho menos se la sabe de memoria y entonces ese campo
> se
> > > quedará vacio por esa razón. Cómo laboro en un Hospital imaginense
> > > ellos requieren q se trabaje lo mas pronto posible con ese
> paciente.
> >
> > ¿No se la saben de memoria? Vaya. Acá todo el mundo se sabe al menos
> > la propia (yo personalmente me sé la mía, la de mi esposa, mi padre
> y mi
> > madre).
> >
> > Supongo que no es asunto tuyo hacer un cambio social para que cada
> uno
> > se las aprenda :-)
> >
> > --
> > Alvaro Herrera http://www.CommandPrompt.com/
> > PostgreSQL Replication, Consulting, Custom Development, 24x7 support
>
>
>


--
Cordialmente.


William Diaz Pabón
Gerente de Tecnología
InfoTech Soluciones Ltda.
Cel: 3173314172 - 3156396316
Tunja - Boyacá - Colombia

Re: [HACKERS] [WIP] patch - Collation at database level

My patch should be "sort of" wrapper that will implement guts for further development (collation at column level) like catalogs, creating collations etc. When creating collation user will be able to choose which function to use (by statement STRCOLFN - not in SQL standard). In the first stage I'll implement function that will use system locales. Adding ICU or any other library won't be that big deal.

Radek Strnad


On Wed, Jul 2, 2008 at 8:22 PM, Gregory Stark <stark@enterprisedb.com> wrote:
"Tom Lane" <tgl@sss.pgh.pa.us> writes:

> Alvaro Herrera <alvherre@commandprompt.com> writes:
>> Why does a collation have a schema?
>
> Because the SQL spec says so.  Also, if we don't put them in schemas,
> we have no nice way to distinguish built-in and user-defined collations,
> which creates a problem for pg_dump.

Out of curiosity, what is a "user-defined collation"? Are there SQL statements
to go around declaring what order code points should be sorted in? That seems
like it would be... quite tedious!

--
 Gregory Stark
 EnterpriseDB          http://www.enterprisedb.com
 Ask me about EnterpriseDB's Slony Replication support!

Re: [HACKERS] PATCH: CITEXT 2.0

> I went through your code and I have following comments/questions:

one more comment:

7) Hash opclass is absent. Hash opclass framework is used for hash join.


--
Teodor Sigaev E-mail: teodor@sigaev.ru
WWW: http://www.sigaev.ru/

--
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] no repetir nombre

La idea de Alvaro de separar nombres y apellidos es muy buena, podría
completarla incluyendo la fecha de nacimiento del individuo, eso
minimiza la población de individuos que se llamen "Juán Perez" y hayan
nacido el mismo día.
De todas formas dependes de la buena voluntad del usuario y ya sabemos
a donde lleva eso....
Exitos


El día 2 de julio de 2008 15:17, Gilberto Castillo Martínez
<gilberto.castillo@etecsa.cu> escribió:
> José Fermín:
>
> Puede ser muchos más engorroso, pero te sugiero uses auto-completamiento
> en los formulario, así los que entran los datos no cometan tantos
> equívocos.
>
> Saludos,
> Gilberto.
> El mié, 02-07-2008 a las 17:06 +0000, José Fermín Francisco Ferreras
> escribió:
>> Asi es mi colegas aquí las cosas son mas complejas q en otros sitios,
>> yo he pensado ponerle un campo q tome el pasaporte, pero, aquí la gran
>> mayoría d las personas no tiene pasaporte.
>>
>> Mientras tanto lo unico q me queda es decir a las personas encargadas
>> d crear a los clientes es q busquen bien y se aseguren d q el cliente
>> está creado o no.
>>
>> Cualquier otras sugerencias seré todo oidos.
>>
>>
>>
>> <html><div>ing. José Fermín Francisco Ferreras <BR>San Francisco de Macorís, Rep. Dom. <BR></div></html>
>>
>>
>>
>> ______________________________________________________________________
>>
>> > Date: Wed, 2 Jul 2008 12:48:36 -0400
>> > From: alvherre@commandprompt.com
>> > To: josefermin54@hotmail.com
>> > CC: jaleman@layconsa.com.pe; pgsql-es-ayuda@postgresql.org
>> > Subject: Re: [pgsql-es-ayuda] no repetir nombre
>> >
>> > José Fermín Francisco Ferreras escribió:
>> > > Gracias a los q han contestado, resulta q aquí (República
>> Dominicana)
>> > > cada persona tiene su Cédula d identificación personal, pero, aquí
>> en
>> > > mi país se da con mucha frecuencia q la gente no lleva la cédula
>> > > consigo y mucho menos se la sabe de memoria y entonces ese campo
>> se
>> > > quedará vacio por esa razón. Cómo laboro en un Hospital imaginense
>> > > ellos requieren q se trabaje lo mas pronto posible con ese
>> paciente.
>> >
>> > ¿No se la saben de memoria? Vaya. Acá todo el mundo se sabe al menos
>> > la propia (yo personalmente me sé la mía, la de mi esposa, mi padre
>> y mi
>> > madre).
>> >
>> > Supongo que no es asunto tuyo hacer un cambio social para que cada
>> uno
>> > se las aprenda :-)
>> >
>> > --
>> > Alvaro Herrera http://www.CommandPrompt.com/
>> > PostgreSQL Replication, Consulting, Custom Development, 24x7 support
>>
>>
>>
>> ______________________________________________________________________
>> Do more with your photos with Windows Live Photo Gallery. Get Windows
>> Live-Free
>
> --
> TIP 8: explain analyze es tu amigo
>
--
TIP 3: Si encontraste la respuesta a tu problema, publícala, otros te lo agradecerán

Re: [GENERAL] Delete from Join

 --- On Wed, 7/2/08, Gwyneth Morrison <postgres@toadware.ca> wrote:  
> From: Gwyneth Morrison <postgres@toadware.ca> > Subject: [GENERAL] Delete from Join > To: pgsql-general@postgresql.org > Date: Wednesday, July 2, 2008, 3:15 PM > Hello, >  > Is it possible to use a join keyword in a delete? >  > For example: >  >      DELETE FROM data_table1 >                 using data_table2 INNER JOIN >                         data_table1  ON data_table1.fkey = > data_table2.pkey; >  >  > It is not directly mentioned in the delete syntax but the > delete refers  > to the select clause where JOIN is valid. >  > G >                  
 >i have a example  >delete from t1 a using t2 b where a.id = b.oid  >A standard way to do it is  >delete from t1 a where id in (select a.id from t1 a inner join t2 b on (a.id = b.oid))    Thank you for your reply,   You are absolutely correct, it IS the standard way.   What I am actually trying to do here is write a program to convert MS SQL to Postgres. I have had quite a bit of success so far, but this is a sticking point.   Apparently using the JOIN keyword directly in a delete statement is valid in MS. I am trying to determine if it is valid in postgres which I figure it is not but cannot  find it exactly in the documentation.   So I guess the real question is, can the JOIN keyword be used directly in a delete as above.  G   
-- 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] [WIP] patch - Collation at database level

On Wed, Jul 02, 2008 at 07:22:10PM +0100, Gregory Stark wrote:
> > Because the SQL spec says so. Also, if we don't put them in schemas,
> > we have no nice way to distinguish built-in and user-defined collations,
> > which creates a problem for pg_dump.
>
> Out of curiosity, what is a "user-defined collation"? Are there SQL statements
> to go around declaring what order code points should be sorted in? That seems
> like it would be... quite tedious!

Not that we'll ever use it, but ICU for example allows users to say:
"use collation X but move this code point somewhere else", essentially
allowing users tweak the collation on a small scale. In any case,
whatever collation library is used, we're unlikely to predefine every
possible collation in the system, there's too many (assuming they're
denumerable).

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

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

Re: [pgsql-es-ayuda] Re[2]: [pgsql-es-ayuda] Recomendación para desarrollar aplicación que necesita datos de dos bases distintas

Si las conozco, muchas gracias Gilberto.
No obstante desde el punto de vista de la documentación, orden,
estructura, conformación de la base de datos, a "mi" manera de ver,
cada cosa iría en un esquema que indique de que se trata, en el
público solo aquellas tablas genericas, compartidas por cualquier
aplicación, ej: paises, provincias, tipo_de_documento, etc. pero solo
a nivel teorico, es como un grano en la frente, en la práctica las
tablas pueden estar todas en el esquema público con un prefijo en el
nombre y ya. Pero para eso están los esquemas.
De todas formas, no es el punto del thread que inició Laura.
Resumiendo, Laura:
- Puedes usar un schema "encuestas" en la base de datos "academicos".
- Puedes usar dblink en la base de datos "encuestas" para crear una
vista a las tablas de la base de datos "academicos", aunque esta es
desaconsejada por gente del foro que tiene muchas experiencia como
Alvaro.
- Puedes crear las tablas en la base de datos "estadísticas" y correr
un script de sincronización. (menos recomendable aún)
Saludos.
José Luis

El día 2 de julio de 2008 15:08, Gilberto Castillo Martínez
<gilberto.castillo@etecsa.cu> escribió:
> José Luis:
>
> Te dejo unas notas de como trabajar con esquemas si interferir en las
> aplicaciones... espero te ayude.
>
> Trabajando con esquemas.
> En ocasiones queremos llamar una tabla que está en un esquema
> determinado, pero sin poner el prefijo del esquema por ejemplo: select *
> from esquema1.tabla1; sino poner solamente select * from tabla1, para
> esto se puede decirle al usuario logeado el orden en que va a buscar en
> los esquemas:
>
> SET search_path TO esquema1,public;
>
> Para hacerlo permanente ponemos
>
> ALTER USER test SET search_path TO esquema1,public;
>
> Saludos,
> Gilberto.
>
> El mié, 02-07-2008 a las 12:31 -0300, Jose Luis Balle escribió:
>> Desordenar en el sentido de que la base de datos original no contempla
>> esquemas, es como si a la base de datos recursos humanos que reside en
>> el esquema publico le pongo un esquema inspecciones para poder tomar
>> los datos del personal.
>> Por ahí me cuesta tomar el esquema público como un esquema más, no se,
>> pero para utilizar esquemas y que quede prolijo (algo muy subjetivo)
>> el diseño debería haber arrancado con esquemas, si ya tiene todo
>> armado en el público cuando las tablas no son de acceso publico... en
>> fin, algo muy subjetivo y tal vez no viene al caso.
>>
>> El día 2 de julio de 2008 12:02, Alvaro Herrera
>> <alvherre@commandprompt.com> escribió:
>> > Jose Luis Balle escribió:
>> >> Alvaro, se que es incomodo el dblink, pero se justifica desordenar el
>> >> esquema de la base de datos de los alumnos solo para poder tomar
>> >> identificadores aislados como materia, alumno,etc?
>> >
>> > ¿Desordenar el esquema en qué sentido?
>> >
>> >> Si luego quisieran explotar la información de estadísticas sin afectar
>> >> el rendimiento de academicos...
>> >
>> > En ese caso lo ideal es sacar los datos a una réplica y ejecutar los
>> > procesos de reporte en la réplica.
>> >
>> >> Con los esquemas quedaría la base de datos "academicos" con un esquema
>> >> "estadisticas" dentro, entonces en el esquema público tendría todas
>> >> las tablas de academicos que utilizas actualmente y en el esquema
>> >> "estadísticas" solo las que va a utilizar ahora.
>> >
>> > No veo en qué sentido eso sea un problema.
>> >
>> > --
>> > Alvaro Herrera

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

--
Informático:
Persona falta de recursos que, partiendo de premisas falsas y de
especificaciones inconsistentes e incompletas, dirigido por
incompetentes y utilizando herramientas que no funcionan es capaz de
iniciar un proyecto de dudoso éxito realizando una obra de arte que
,por supuesto, es cara y no tiene otro fin que dar prestigio a la
empresa que ha contratado sus servicios.
http://islamanzana.es/desarrollo-de-software/definicion-de-informatico
--
TIP 3: Si encontraste la respuesta a tu problema, publícala, otros te lo agradecerán

Re: [PERFORM] Select running slow on Postgres

On Wed, Jul 2, 2008 at 1:01 PM, samantha mahindrakar
<sam.mahindrakar@gmail.com> wrote:
> I ran the explain analyze.Here is what i got:
>
>
> "Group (cost=112266.37..112266.40 rows=1 width=56) (actual
> time=5583.399..5615.476 rows=13373 loops=1)"
> " -> Sort (cost=112266.37..112266.38 rows=1 width=56) (actual
> time=5583.382..5590.890 rows=13373 loops=1)"
> " Sort Key: lane_data_07_08.lane_id,
> lane_data_07_08.measurement_start, lane_data_07_08.measurement_end,
> lane_data_07_08.speed, lane_data_07_08.volume, lane_data_07_08.occupancy,
> lane_data_07_08.quality, lane_data_07_08.effective_date"
> " -> Nested Loop IN Join (cost=0.00..112266.36 rows=1 width=56)
> (actual time=1100.307..5547.768 rows=13373 loops=1)"
> " -> Seq Scan on lane_data_07_08 (cost=0.00..112241.52 rows=3
> width=56) (actual time=1087.666..5341.662 rows=20581 loops=1)"

You can see here that the seq scan on lane_data is what's eating up
all your time. Also, since the row estimate is WAY off, it then chose
a nested loop thinking it would be joining up only 1 row and actually
running across 20k rows.

> " Filter: (((volume = 255::double precision) OR (speed =
> 255::double precision) OR (occupancy = 255::double precision) OR (occupancy
>>= 100::double precision) OR (volume > 52::double precision) OR (volume <
> 0::double precision) OR (speed > 120::double precision) OR (speed <
> 0::double precision)) AND (date_part('hour'::text, measurement_start) >=
> 5::double precision) AND (date_part('hour'::text, measurement_start) <=
> 23::double precision) AND (date_part('day'::text, measurement_start) =
> 1::double precision))"
> " -> Index Scan using lane_info_pk on
> lane_info (cost=0.00..8.27 rows=1 width=4) (actual time=0.007..0.007 rows=1
> loops=20581)"
> " Index Cond: (lane_data_07_08.lane_id =
> lane_info.lane_id)"
> " Filter: (inactive IS NULL)"
> "Total runtime: 5621.409 ms"
>
>
> Well instaed of creating extra indexes (since they eat up lot of space) i
> made use of the whole measurement_start field, so thet it uses the index
> proeprty and makes the search faster.
> So i changed the query to include the measuerment start as follows:
>
> SELECT lane_id,measurement_start,
> measurement_end,speed,volume,occupancy,quality,effective_date
> FROM tss.lane_data_06_08
> WHERE lane_id in(select lane_id from lane_info where inactive is null )
> AND measurement_start between '2008-06-30 05:00:00-04' AND '2008-06-30
> 23:00:00-04'
> GROUP BY
> lane_id,measurement_start,measurement_end,speed,volume,occupancy,quality,effective_date
> ORDER BY lane_id, measurement_start

Yeah, anytime you can just compare date / timestamp on an indexed
field you'll do better. If you find yourself needing to use the other
syntax, so you can, for instance, grab the data for 5 days in a row
from 5am to 11am or something, then the method I mentioned of making
indexes on date_part are a good choice. Note that you need regular
timestamp, not timstamptz to create indexes.

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

Re: [ADMIN] Postgres windows service shutdowns after start

"stats_start_collector" is an obsolete parameter in 8.3, that's why PG
wouldn't start with it.

Igor

-----Original Message-----
From: pgsql-admin-owner@postgresql.org
[mailto:pgsql-admin-owner@postgresql.org] On Behalf Of bogdad
Sent: Wednesday, July 02, 2008 2:38 PM
To: pgsql-admin@postgresql.org
Subject: [ADMIN] Postgres windows service shutdowns after start


Hi,

I have a postgres 8.3 service working on win2003 server, it works fine.

But, when i alter postgresql.conf adding the stats_starts_collector = on
( or even false, which bugs me to the end) the service starts and
immedeately stops. If I revert the change, service works again.

The event log is clear, the pg_log is empty.

My login is local admin, and due to restrictions in environment, i
currently cannot runas /user:postgres posmaster.exe to retrieve the
stderr or stdout of postgres.

So the questions:

1) Is it really connected to stats collector? [ the part in brackets
makes me think it's not]
2) Maybe, there is a forsaken way for admin user to run postgres?
3) How to proceed?
4) Is there a way to syntax check .conf?

(I know that I can send the .conf home and run postgres there, but don't
like this option)

Thanks in advance,
Vladimir.
--
View this message in context:
http://www.nabble.com/Postgres-windows-service-shutdowns-after-start-tp1
8244024p18244024.html
Sent from the PostgreSQL - admin mailing list archive at Nabble.com.


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


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

Re: [PERFORM] Select running slow on Postgres

I ran the explain analyze.Here is what i got:


"Group  (cost=112266.37..112266.40 rows=1 width=56) (actual time=5583.399..5615.476 rows=13373 loops=1)"
"  ->  Sort  (cost=112266.37..112266.38 rows=1 width=56) (actual time=5583.382..5590.890 rows=13373 loops=1)"
"        Sort Key: lane_data_07_08.lane_id, lane_data_07_08.measurement_start, lane_data_07_08.measurement_end, lane_data_07_08.speed, lane_data_07_08.volume, lane_data_07_08.occupancy, lane_data_07_08.quality, lane_data_07_08.effective_date"
"        ->  Nested Loop IN Join  (cost=0.00..112266.36 rows=1 width=56) (actual time=1100.307..5547.768 rows=13373 loops=1)"
"              ->  Seq Scan on lane_data_07_08  (cost=0.00..112241.52 rows=3 width=56) (actual time=1087.666..5341.662 rows=20581 loops=1)"
"                    Filter: (((volume = 255::double precision) OR (speed = 255::double precision) OR (occupancy = 255::double precision) OR (occupancy >= 100::double precision) OR (volume > 52::double precision) OR (volume < 0::double precision) OR (speed > 120::double precision) OR (speed < 0::double precision)) AND (date_part('hour'::text, measurement_start) >= 5::double precision) AND (date_part('hour'::text, measurement_start) <= 23::double precision) AND (date_part('day'::text, measurement_start) = 1::double precision))"
"              ->  Index Scan using lane_info_pk on lane_info  (cost=0.00..8.27 rows=1 width=4) (actual time=0.007..0.007 rows=1 loops=20581)"
"                    Index Cond: (lane_data_07_08.lane_id = lane_info.lane_id)"
"                    Filter: (inactive IS NULL)"
"Total runtime: 5621.409 ms"


Well instaed of creating extra indexes (since they eat up lot of space) i made use of the whole measurement_start field, so thet it uses the index proeprty and makes the search faster.
So i changed the query to include the measuerment start as follows:

SELECT lane_id,measurement_start,
measurement_end,speed,volume,occupancy,quality,effective_date
FROM tss.lane_data_06_08
WHERE lane_id in(select lane_id from lane_info where inactive is  null )
AND measurement_start between '2008-06-30 05:00:00-04' AND  '2008-06-30 23:00:00-04'
GROUP BY lane_id,measurement_start,measurement_end,speed,volume,occupancy,quality,effective_date
ORDER BY lane_id, measurement_start


Samantha

On 7/1/08, Scott Marlowe <scott.marlowe@gmail.com> wrote:
> On Tue, Jul 1, 2008 at 1:29 PM, samantha mahindrakar
> <sam.mahindrakar@gmail.com> wrote:
> > Hi
> > I have a select statement that runs on a partition having say couple
> > million rows.
> > The tabel has indexes on two colums. However the query uses the
> > non-indexed colums too in its where clause.
> > For example:
> > SELECT lane_id,measurement_start,
> > measurement_end,speed,volume,occupancy,quality,effective_date
> >  FROM tss.lane_data_06_08
> >  WHERE lane_id in(select lane_id from lane_info where inactive is  null )
> >  AND date_part('hour', measurement_start) between 5 and 23
> >  AND date_part('day',measurement_start)=30
> > GROUP BY lane_id,measurement_start,measurement_end,speed,volume,occupancy,quality,effective_date
> > ORDER BY lane_id, measurement_start
> >
> > out of this only lane_id and mesaurement_start are indexed. This query
> > will return around 10,000 rows. But it seems to be taking a long time
> > to execute which doesnt make sense for a select statement. It doesnt
> > make any sense to create index for every field we are gonna use in tne
> > where clause.
> > Isnt there any way we can improve the performance?
>
> I'm guessing that adding an index for either
> date_part('hour',measurement_start) or
> date_part('day',measurement_start) or both would help.
>
> What does explain analyze select ... (rest of query here) say?
>

[ADMIN] Postgres windows service shutdowns after start

Hi,

I have a postgres 8.3 service working on win2003 server,
it works fine.

But, when i alter postgresql.conf adding the stats_starts_collector = on (
or even false, which bugs me to the end) the service starts and immedeately
stops. If I revert the change, service works again.

The event log is clear, the pg_log is empty.

My login is local admin, and due to restrictions in environment, i currently
cannot runas /user:postgres posmaster.exe to retrieve the stderr or stdout
of postgres.

So the questions:

1) Is it really connected to stats collector? [ the part in brackets makes
me think it's not]
2) Maybe, there is a forsaken way for admin user to run postgres?
3) How to proceed?
4) Is there a way to syntax check .conf?

(I know that I can send the .conf home and run postgres there,
but don't like this option)

Thanks in advance,
Vladimir.
--
View this message in context: http://www.nabble.com/Postgres-windows-service-shutdowns-after-start-tp18244024p18244024.html
Sent from the PostgreSQL - admin mailing list archive at Nabble.com.


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

Re: [pgsql-es-ayuda] no repetir nombre

Alvaro Herrera dijo [Wed, Jul 02, 2008 at 12:48:36PM -0400]:
> ¿No se la saben de memoria? Vaya. Acá todo el mundo se sabe al menos
> la propia (yo personalmente me sé la mía, la de mi esposa, mi padre y mi
> madre).
>
> Supongo que no es asunto tuyo hacer un cambio social para que cada uno
> se las aprenda :-)

En algunos países mal planeados, hemos tenido tantas identificaciones
"únicas" en la historia que... ni nos preocupamos por aprenderla ;-)
Además, por errores aún más estúpidos, por alguna razón algunas
personas (como yo) fuimos registrados con más de una Clave Única de
Registro Poblacional (en mi caso, WOIG760426HDFLSN02 y
WOIG760426HDFLSN02). Pero claro, el CURP se usa aún relativamente
poco, es mucho más común identificarte por el RFC (WOIG760427PC2), que
-como fue creado hace muuuchos años, supongo que antes de que hubiera
coordinación entre los Estados- registra demasiados duplicados. Pero
bueno, el que llevo siempre conmigo (porque siempre pueden pedirte ver
la identificación) es el registro electoral (clave WLISGN76042709H901
folio 0000107555904 credencial 0359050023001 - En diferentes lugares
he visto que usen los tres distintos números, no me pregunten la
razón). Y claro, ahora que puse acá todos mis números, cualquierda de
ustedes puede suplantar mi personalidad.

Bah.

--
Gunnar Wolf - gwolf@gwolf.org - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
--
TIP 2: puedes desuscribirte de todas las listas simultáneamente
(envía "unregister TuDirecciónDeCorreo" a majordomo@postgresql.org)

[GENERAL] SET CLIENT_ENCODING

Hallo,

I would to ask about function (vide subject) transcoding the characters
between different character pages "on the fly": is it smart enough to skip
any transcoding operation, when both client and database are set to use
the same encoding already?

To make it more clear: I've got an application, which always uses LATIN2
encoding, and wants database using this encoding. Unfortunately, some
Postgres packages allow to set it - but some are "UTF-8 only". I'm wondering,
whether can I add into application command "SET CLIENT_ENCODING TO 'LATIN2';"
for steady, or it should be kept optional?

I would to avoid situation, when Postgres will transcode "from LATIN2 to
LATIN2". Perhaps someone knows the details, how is it working in practice?
--
pozdrawiam / regards

Zbigniew Baniewski

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

Tuesday, July 1, 2008

[HACKERS] Please claim review items for commit fest!

Hackers,

Just in case anyone was unclear, this is how we're trying things for
this commitfest:

1) Starting RIGHT NOW, reviewers should claim review items they are
interested in or specially qualified to review.

2) This weekend, I will check for all items which don't have one or
more reviewers and parcel them out to the Round Robin Reviewers who
don't already have patches to review.

You do not have to be a committer to be a reviewer. Anyone who knows C
code and is familiar with Postgres

Josh Berkus
PostgreSQL @ Sun
San Francisco 415-752-2500

--
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] TODO assignment

Jiri,

I don't know of anyone currently working on the "apply permissions to
all objects" TODO. You're welcome to take a stab at it.

--Josh

Josh Berkus
PostgreSQL @ Sun
San Francisco 415-752-2500

--
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] Memory use in 8.3 plpgsql with heavy use of xpath()

> Ugh. Sounds like "small memory leak inside libxml2" --- probably not
> going to be easy to find. Can you put together a self-contained test
> case?

OK, I'll try to come up with something. Do you have a recommended way of
capturing the amount memory being used by Postgres related to this? I was
thinking I would have a plpgsql function that loops a large number of
times, calling a few xpath() calls, and could take a memory snapshot
before/after the function completes. Is there a call within Postgres I can
make, or should I just rely on OS-level tools for this?

-- m@

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

Re: [SQL] column default dependant on another columns value

> -----Mensaje original-----
> De: Richard Broersma [mailto:richard.broersma@gmail.com]
>
> It is possible to do this with a trigger or a rule. A
> trigger would be more robust.
>
> > Is this correct? Is there another (better/simpler) way to
> achieve this?
>
> Well I might work, but it is a bad practice to get into since
> what you are trying to do violates the rules of database
> normalization.
>
> Wouldn't it be better to calculate the minutes with you query
> your table?
>
> SELECT *, seconds / 60 AS minutes
> FROM yourtable;

Actually I only used this as an example.
The real table is queried lots of times for millions of rows and the server
is showing some high-level user cpu consumption. There are a couple
calculated columns on the table so I am trying to reduce cpu usage by
pre-calculating the more cpu intensive data once on insert. Enhancing the
application is currently not possible.

Anyway, the rule didn't work. Got "an infinite recursion error" when
inserting on the table.
Can't figure out where the recursion is as supposedly the rule kicks in when
the "where minutes is null" condition is satisfied. The DO INSTEAD part runs
an insert were minutes is NOT null so the rule should be ignored.
Where is the recursion then? I am on postgres 8.2.9.

Thanks for your hindsight Richard. I Will look into the trigger solution.
Still, I'd like to understand this recursion error.

Regards,
Fernando.

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

Re: [PATCHES] LOCK_DEBUG documentation

Greg Sabino Mullane wrote:
[ There is text before PGP section. ]
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: RIPEMD160
>
>
> Tom Lane replied:
> >> Documentation patch by Kevin L. McBride explaining LOCK_DEBUG options
> >> in detail.
>
> > Should this stuff really go into the SGML documentation, when these
> > options will certainly never be enabled anywhere except in developers'
> > private builds? A few lines of comments in pg_config_manual.h seems
> > a more appropriate solution.
>
> Call me a traditionalist, but I like all the documentation in one place,
> even if some of it it seldom used. For the record, these options have
> been enabled by myself and others in production systems for debugging
> purposes, and the lack of detail in that section while doing so led to
> the patch. The docs also has the advantage of being more available,
> searchable, and found via the web.

Agreed, applied.

--
Bruce Momjian <bruce@momjian.us>

http://momjian.us

EnterpriseDB

http://enterprisedb.com

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

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

[COMMITTERS] pgsql: Documentation patch by Kevin L.

Log Message:
-----------
Documentation patch by Kevin L. McBride explaining GUC lock variables,
which are available if LOCK_DEBUG is defined.

Modified Files:
--------------
pgsql/doc/src/sgml:
config.sgml (r1.181 -> r1.182)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/config.sgml?r1=1.181&r2=1.182)

--
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] Problem with roles and permissions

That did it! Thanks, all.

(Out of curiosity, what's the reason for not making this the default? It seems to me that if you're making a role a child of another role, it's /because/ you want to inherit permissions. OTOH maybe defaulting to more security is smart enough to be worth the confusion...)

-cb.

> I think it's the other way around --- the login role needs the INHERIT property. Anyway, one or the other should do it.

regards, tom lane


No virus found in this incoming message.
Checked by AVG.
Version: 7.5.526 / Virus Database: 270.4.3/1528 - Release Date: 7/1/2008 7:26 AM

No virus found in this outgoing message.
Checked by AVG.
Version: 7.5.526 / Virus Database: 270.4.3/1528 - Release Date: 7/1/2008 7:26 AM


--
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] Commitfest status?

On Tue, 01 Jul 2008 16:19:39 -0400
Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Well, it's July 1, and time for another commit fest to begin.
> Do we have all the submitted patches queued up at
> http://wiki.postgresql.org/wiki/CommitFest:2008-07 ?

I think Bruce and I have added everything submitted to June 29. I've
been offline for 36 hours, though, so I'm scanning hackers and patches
now. Help welcomed -- I'm on dial-up and it's slow.

Time for people to start volunteering to review stuff! I'll start
round-robin after a few days. So put your names on the stuff you know
you can review now.

Josh Berkus
PostgreSQL @ Sun
San Francisco 415-752-2500

--
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] Memory use in 8.3 plpgsql with heavy use of xpath()

"Matt Magoffin" <postgresql.org@msqr.us> writes:
> Later, I added a large set of plpgsql trigger functions that operate on
> that new xml column data, using the xpath() function to extract bits of
> XML and populate them into normal tables. The server has been running in
> this fashion for many months now, and there is a noticeable difference in
> how Postgres is using memory now, in that over time it's non-shared memory
> use is climbing higher and higher. Right now I'm tracking this from data
> captured by Munin on the system. The memory creep is very slight, but over
> many months is easy to discern.

Ugh. Sounds like "small memory leak inside libxml2" --- probably not
going to be easy to find. Can you put together a self-contained test
case?

regards, tom lane

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

Re: [ADMIN] Change a character in a text field

>>> Naomi Walker <nwalker@mhs.mphasis.com> wrote:
> Is there some way with a SQL state to interrogate a text field, and
> replace characters.
>
> For example, we would like all "|"'s to be changed to something else,
on
> a regular basis...

It sounds like you might want to look at the regexp_replace function:

http://www.postgresql.org/docs/8.3/interactive/functions-matching.html#FUNCTIONS-POSIX-REGEXP


Be sure to use a WHERE clause on your UPDATE with the ~ operator.

-Kevin

--
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] Problem with roles and permissions

Alvaro Herrera <alvherre@commandprompt.com> writes:
> Probably your group role needs to have the INHERIT property set.

I think it's the other way around --- the login role needs the INHERIT
property. Anyway, one or the other should do it.

regards, tom lane

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

[HACKERS] Should enum GUCs be listed as such in config.sgml?

Currently, config.sgml still describes the new "enum" GUC variables
as being of type "string" --- but pg_settings says they are "enum".
This is not very consistent, but I wonder whether changing the docs
would be more confusing or less so. I note that section 18.1 doesn't
mention the enum alternative either.

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: [GENERAL] Problem with roles and permissions

Chandra Barnett wrote:

> What I've done so far is to set up a "group role" and explicitly
> granted it every possible type of permission on the database in
> question, and also on the individual relations in that database. Then
> I created a "login role" and made it part of the group role I created.
> I expected that to let me connect to the dbms using that login role
> and database, and that I'd then be able to select/insert/update/delete
> in the relations in that database. I can connect just fine to that
> database with that login role, as I expected, but I then can't execute
> any commands.

Probably your group role needs to have the INHERIT property set.
Alternatively, you could "SET ROLE group" after connecting.

> It seems there must be some other step that I didn't know to do. In
> MySQL, for example, after changing permissions, one needs to "flush
> privileges" to get everything to take effect. Is there something
> analogous to this in PostgreSQL?

Fortunately not.

--
Alvaro Herrera

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

--
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: Remove GUC extra_desc strings that are redundant with the enum

Log Message:
-----------
Remove GUC extra_desc strings that are redundant with the enum value lists.

Modified Files:
--------------
pgsql/src/backend/utils/misc:
guc.c (r1.460 -> r1.461)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/misc/guc.c?r1=1.460&r2=1.461)

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

Re: [planet] Aggregating a new blog to www.planetpostgresql.org

Sorry for the late response.

Could you please add a category (blogger calls it something different
that I cannot recall right now) for PostgreSQL? I'd rather not add the
whole blog to Planet PostgreSQL.

Regards, Devrim

On Mon, 2008-06-02 at 22:03 -0700, Devrim GÜNDÜZ wrote:
> On Mon, 2 Jun 2008, Robert Hodges wrote:
>
> > Hi,
> >
> > Can you aggregate my blog to PlanetPostgreSQL? It's located at:
> >
> > http://scale-out-blog.blogspot.com/feeds/posts/default
> >
> > It has PostgreSQL/MySQL posts for the most part.
> >
> > Thanks!
> >
> > Robert
> > --
> > Robert Hodges, CTO, Continuent, Inc.
> > Email: robert.hodges@continuent.com
> > Mobile: +1-510-501-3728 Skype: hodgesrm
> >
> >
>
> --
> Devrim GÜNDÜZ
> RHCE, PostgreSQL Consultant @ Command Prompt, Inc.
>

http://www.CommandPrompt.com
> devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
>

http://www.gunduz.org
--
Devrim GÜNDÜZ
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr

http://www.gunduz.org

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

Re: [HACKERS] Commitfest status?

Joe Conway wrote:

> I haven't yet committed the dblink patch posted here:
>
> http://archives.postgresql.org/pgsql-patches/2008-06/msg00016.php
>
> Should I post it on the wiki before committing? Either way I'll commit
> in the next day or so.

It doesn't matter. Patches are only listed in the wiki so that we don't
forget about them, or if you want someone else to review them.

--
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

Re: [planet] Me And My Database

Hi,

Sorry for the delay -- You just landed Planet. Welcome aboard.

Regards, Devrim

On Mon, 2008-06-23 at 22:01 -0700, Devrim GÜNDÜZ wrote:
> On Tue, 24 Jun 2008, Leif B. Kristensen wrote:
>
> > Devrim,
> > I've got this blog called "Me And My Database :: Geek Genealogy" that's
> > about my hobby genealogy project, developed and running in a Linux /
> > Apache / PostgreSQL / PHP environment. There's a lot of PostgreSQL
> > stuff there. The address is <http://solumslekt.org/blog/> and the feed
> > is <feed:http://solumslekt.org/blog/?feed=rss2>.
> >
> > I'd be happy to be included in the Planet PostgreSQL.
> > --
> > Leif Biberg Kristensen | Registered Linux User #338009
> > Me And My Database: http://solumslekt.org/blog/
> > My Jazz Jukebox: http://www.last.fm/user/leifbk/
> >
>
> --
> Devrim GÜNDÜZ
> RHCE, PostgreSQL Consultant @ Command Prompt, Inc.
>

http://www.CommandPrompt.com
> devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
>

http://www.gunduz.org
--
Devrim GÜNDÜZ
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr

http://www.gunduz.org

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

Re: [planet] Can I have my feed shown on planetpostgresql.org?

Sorry for the delay -- you just landed Planet. Welcome aboard.

Regards, Devrim

On Tue, 2008-06-24 at 07:47 -0700, Devrim GÜNDÜZ wrote:
> On Tue, 24 Jun 2008, Kenny Gorman wrote:
>
> > Devrim,
> >
> > I just wanted to check back in and see if you are still considering linking
> > me. ;-). Please let me know you received this if you wound not mind.
> >
> > Thanks!
> > Kenny
> >
> > On Jun 5, 2008, at 5:24 PM, Kenny Gorman wrote:
> >
> >>
> >> Devrim,
> >>
> >> Sure, here you go, I think this works..
> >>
> >>
> >>
> >> -kg
> >>
> >> > On May 30, 2008, at 12:41 AM, Devrim GÜNDÜZ wrote:
> >> >
> >> > >
> >> > > Hi,
> >> > >
> >> > > Do you have a specific category for PostgreSQL, which includes all
> >> > > PostgreSQL related stuff? I'd like to pull that one instead of whole
> >> > > feed.
> >> > >
> >> > > Regards, Devrim
> >> > >
> >> > > On Wed, 28 May 2008, Kenny Gorman wrote:
> >> > >
> >> > > > I generally blog about PostgreSQL, Slony, Oracle, python, scalability
> >> > > > and other fun DB related stuff, I work at www.hi5.com where we do
> >> > > > some fun stuff with PostgreSQL.
> >> > > >
> >> > > > site:
> >> > > >
> >> > > > www.kennygorman.com
> >> > > >
> >> > > > feed:
> >> > > >
> >> > > > http://www.kennygorman.com/wordpress/?feed=atom
> >> > > >
> >> > >
> >> > > --
> >> > > Devrim GÜNDÜZ
> >> > > RHCE, PostgreSQL Consultant @ Command Prompt, Inc.
> >> > >

http://www.CommandPrompt.com
> >> > > devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
> >> > >

http://www.gunduz.org
> >> >
> >>
> >
> >
>
> --
> Devrim GÜNDÜZ
> RHCE, PostgreSQL Consultant @ Command Prompt, Inc.
>

http://www.CommandPrompt.com
> devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
>

http://www.gunduz.org
--
Devrim GÜNDÜZ
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr

http://www.gunduz.org

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

[ADMIN] Change a character in a text field

Is there some way with a SQL state to interrogate a text field, and
replace characters.

For example, we would like all "|"'s to be changed to something else, on
a regular basis...
We could unload the rows, change them, and load back, but was hoping
someone had
a slicker way to do it in place..

Thanks,
Naomi

--
------------------------------------------------------------------------
Naomi Walker Chief Information Officer
Eldorado Computing, Inc nwalker@eldocomp.com
---An EDS Company 602-604-3100
------------------------------------------------------------------------
The more I want to get something done, the less I call it work.
- Richard Bach
------------------------------------------------------------------------

-- CONFIDENTIALITY NOTICE --

Information transmitted by this e-mail is proprietary to MphasiS and/or its Customers and is intended for use only by the individual or entity to which it is addressed, and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient or it appears that this e-mail has been forwarded to you without proper authority, you are notified that any use or dissemination of this information in any manner is strictly prohibited. In such cases, please notify us immediately at mailmaster@mphasis.com and delete this mail from your records.

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

Re: [HACKERS] Commitfest status?

Tom Lane wrote:
> Well, it's July 1, and time for another commit fest to begin.
> Do we have all the submitted patches queued up at
> http://wiki.postgresql.org/wiki/CommitFest:2008-07 ?
>

I haven't yet committed the dblink patch posted here:

http://archives.postgresql.org/pgsql-patches/2008-06/msg00016.php

Should I post it on the wiki before committing? Either way I'll commit
in the next day or so.

Joe

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

[GENERAL] Problem with roles and permissions

 
Hi --
 
I've recently started using PostgreSQL after working with MySQL for quite a while. I've been trying to set up roles so I can manage permissions per-user, but it's not working the way I expected and I'm wondering if anyone can steer me straight.
 
What I've done so far is to set up a "group role" and explicitly granted it every possible type of permission on the database in question, and also on the individual relations in that database. Then I created a "login role" and made it part of the group role I created. I expected that to let me connect to the dbms using that login role and database, and that I'd then be able to select/insert/update/delete in the relations in that database. I can connect just fine to that database with that login role, as I expected, but I then can't execute any commands. A sample error message from a failed INSERT is "ERROR:  permission denied for relation sessions". A look in pgAdmin, however, tells me that I've explicitly granted the group role all permissions on both the relation and the database it's in.
 
It seems there must be some other step that I didn't know to do. In MySQL, for example, after changing permissions, one needs to "flush privileges" to get everything to take effect. Is there something analogous to this in PostgreSQL? If so, can someone tell me how to do it via pgAdmin III?
 
For context, I'm using PostgreSQL 8.3 and pgAdmin III on Windows XP.
 
Thanks for your help!
--  Chandra Barnett <chandra.barnett@cognition.com> 310-641-7200 x207 Software Engineer, Cognition, Inc. <http://www.cognition.com> 
 

Re: [SQL] column default dependant on another columns value

On Tue, Jul 1, 2008 at 1:12 PM, Fernando Hevia <fhevia@ip-tel.com.ar> wrote:

> Given a table with columns seconds and minutes, how can I have minutes be
> computed automatically at the insert statement?

It is possible to do this with a trigger or a rule. A trigger would
be more robust.

> Is this correct? Is there another (better/simpler) way to achieve this?

Well I might work, but it is a bad practice to get into since what you
are trying to do violates the rules of database normalization.

Wouldn't it be better to calculate the minutes with you query your table?

SELECT *, seconds / 60 AS minutes
FROM yourtable;


--
Regards,
Richard Broersma Jr.

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

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

[GENERAL] Memory use in 8.3 plpgsql with heavy use of xpath()

I've been using Postgres 8.3 in a production environment for some time
now, and have noticed a difference in long-term non-shared memory use by
Postgres since upgrading the system from 8.1. After initially making the
switch to 8.3 and making only one schema change (changed a text column to
xml) the server ran and used memory more or less the same as it had in
8.1.

Later, I added a large set of plpgsql trigger functions that operate on
that new xml column data, using the xpath() function to extract bits of
XML and populate them into normal tables. The server has been running in
this fashion for many months now, and there is a noticeable difference in
how Postgres is using memory now, in that over time it's non-shared memory
use is climbing higher and higher. Right now I'm tracking this from data
captured by Munin on the system. The memory creep is very slight, but over
many months is easy to discern.

I was wondering if anyone else out there is making heavy use of xpath()
and related functions in plpgsql functions, and if they've noticed a trend
like this? Is this normal for Postgres to accumulate non-shared memory
over time, up to some configured maximum?

A second question I have about is about plpgsql and memory use in general.
If I run some of these plpgsql functions using a lot of xpath() calls on
large sets of data, huge amounts of memory are consumed (gigabytes) and
the memory seems to accumulate until the transaction the functions are
running in completes. Do invocations of plpgsql functions retain memory
they used until the end of the transaction?

-- m@

--
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] pg crashing

"Roberts, Jon" <Jon.Roberts@asurion.com> writes:
> Version: "PostgreSQL 8.3.0, compiled by Visual C++ build 1400"

Well, there are plenty of known bugs in 8.3.0 by now. You really
should update before complaining, not after.

> Problem: My database keeps on crashing every few days with this type of
> error message:

> 2008-07-01 10:46:30 CDT LOG: all server processes terminated;
> reinitializing

I think your real problem is with what happened *before* that.
But:

> 2008-07-01 10:46:31 CDT FATAL: pre-existing shared memory block is
> still in use
> 2008-07-01 10:46:31 CDT HINT: Check if there are any old server
> processes still running, and terminate them.

Hmm ... the code in win32_shmem.c that generates this message seems
mighty bogus to me --- it's just hoping that one-second delay is
enough. Another problem is that postmaster children that do
PGSharedMemoryDetach will still have valid inherited handles for
the shmem segment --- does that factor into the behavior? It looks
to me like the CloseHandle ought to be in PGSharedMemoryDetach.

regards, tom lane

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

[GENERAL] pg crashing

Platform: Windows 2003 Server 32 bit
Windows SharedSection set to 1024,3072 based on recommendations from
http://www.postgresql.org/docs/faqs.FAQ_windows.html#4.4 and
http://support.microsoft.com/kb/184802
Version: "PostgreSQL 8.3.0, compiled by Visual C++ build 1400"
Autovacuum: on
Virus Scanning: disabled on PostgreSQL home directory
Problem: My database keeps on crashing every few days with this type of
error message:

2008-07-01 10:46:30 CDT LOG: all server processes terminated;
reinitializing
2008-07-01 10:46:31 CDT FATAL: pre-existing shared memory block is
still in use
2008-07-01 10:46:31 CDT HINT: Check if there are any old server
processes still running, and terminate them.


Is this problem fixed in 8.3.3 and/or fixed by moving to a Unix
environment like Solaris?


Jon

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

[HACKERS] Commitfest status?

Well, it's July 1, and time for another commit fest to begin.
Do we have all the submitted patches queued up at
http://wiki.postgresql.org/wiki/CommitFest:2008-07 ?

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: [BUGS] problema con pg_dum

On Tue, 01 Jul 2008 19:44:28 +0200, Avilio Alarcón
<aalarcon@grupoaventura.com.py> wrote:
> pg_dump: not found
I have no idea what you just said, but I think I understand the problem.
Cron's PATH is reset to quite simple value in each cron script, so,
instead of:
> pg_dump -Ft -b radius > $(date +%Y%m%d)_aloradius_radius.tar
use
> /usr/bin/pg_dump -Ft -b radius > $(date +%Y%m%d)_aloradius_radius.tar
(or wherever your pg_dump is)
I'd also suggest using /bin/gzip instead of just gzip.

Regards,
--
ru

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

[SQL] column default dependant on another columns value

Hi list,

Given a table with columns seconds and minutes, how can I have minutes be
computed automatically at the insert statement?

I tried:

ALTER TABLE table1 ALTER COLUMN minutes SET default (seconds/60);

Postgres' answer was:
ERROR: cannot use column references in default expression

So I gave rules a look but it seems rules apply to the entire row.

CREATE RULE "my_rule" AS ON
INSERT TO table1
WHERE minutes is null
DO INSTEAD
INSERT INTO table1 (column1, column2, seconds, minutes)
VALUES(new.column1, new.column2, new.seconds, new.seconds/60);

Is this correct? Is there another (better/simpler) way to achieve this?

Regards,
Fernando


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

Re: [HACKERS] Location for pgstat.stat

Magnus Hagander <magnus@hagander.net> writes:
> Alvaro Herrera wrote:
>> Well, it doesn't :-) No database or table will be processed until stat
>> entries are created, and then I think it will first wait until enough
>> activity gathers to take any actions at all.

> That's not actualliy not affected, but it does seem like it wouldn't be
> a very big issue. If one table was just about to be vacuumed or
> analyzed, this would just push it up to twice the threshold, right?

Except you could lather, rinse, repeat indefinitely.

The stats system started out with the idea that the stats were
disposable, but I don't really think that's an acceptable behavior
today. We don't even have stats_reset_on_server_start anymore.

It doesn't seem to me that it'd be hard to support two locations for the
stats file --- it'd just take another parameter to the read and write
routines. pgstat.c already knows the difference between a normal write
and a shutdown write ...

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: [GENERAL] Version 8.2.6 - ecpg: current_timestamp - how to control timezone

paul tilles <Paul.Tilles@noaa.gov> writes:
> How do we set the time zone for current_timestamp to be UTC?

http://www.postgresql.org/docs/8.2/static/datatype-datetime.html#DATATYPE-TIMEZONES

regards, tom lane

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

Re: [ADMIN] After upgrade cleanup

On Fri, Jun 20, 2008 at 3:19 PM, Decibel! <decibel@decibel.org> wrote:
> On Jun 19, 2008, at 8:13 AM, Carol Walter wrote:
>>
>> I just did an upgrade from 8.1 to 8.2.3. We'll go up to 8.3.3 very soon,
>> but for reasons I won't go into, this intermediate step was necessary. My
>> problem is, now that the upgrade is done, how can I clean up the database
>> from the old version. I leave the original database up as long as I can
>> when I do an upgrade just in case I need to revert to it. Now I have the
>> databases from two versions on my server and I need to get rid of the old
>> one. Can I just remove the old files from the data directories? With other
>> systems, I've had trouble removing database files because upgrades use
>> certain files from old versions. I don't want to break my new database.
>> I'm on Solaris 10.
>
>
> Not only does the new version not use files from the old, it doesn't even
> know it exists. You can just nuke all the 8.1 stuff.

If you're paranoid, then you can also do:

sudo chmod 000 /old/data/dir

and see if anything breaks.

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

Re: [HACKERS] Location for pgstat.stat

On Tue, 1 Jul 2008, Tom Lane wrote:

> Magnus Hagander <magnus@hagander.net> writes:
>> Tom Lane wrote:
>>> Hmm ... that would almost certainly result in the stats being lost over
>>> a system shutdown. How much do we care?
>
>> Only for those who put it on a ramdrive. The default, unless you
>> move/sync it off, would still be the same as it is today. While not
>> perfect, the performance difference of going to a ramdrive might easily
>> be enough to offset that in some cases, I think.
>
> Well, what I was wondering about is whether it'd be worth adding logic
> to copy the file to/from a "safer" location at startup/shutdown.

Anyone who needs fast stats storage enough that they're going to symlink
it to RAM should be perfectly capable of scripting server startup/shutdown
to shuffle that to/from a more permanent location. Compared to the admin
chores you're likely to encounter before reaching that scale it's a pretty
easy job, and it's not like losing that data file is a giant loss in any
case. The only thing I could see putting into the server code to help
support this situation is rejecting an old stats file and starting from
scratch instead if they restored a previous version after a crash that
didn't save an updated copy.

--
* 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: [PERFORM] Select running slow on Postgres

On Tue, Jul 1, 2008 at 1:29 PM, samantha mahindrakar
<sam.mahindrakar@gmail.com> wrote:
> Hi
> I have a select statement that runs on a partition having say couple
> million rows.
> The tabel has indexes on two colums. However the query uses the
> non-indexed colums too in its where clause.
> For example:
> SELECT lane_id,measurement_start,
> measurement_end,speed,volume,occupancy,quality,effective_date
> FROM tss.lane_data_06_08
> WHERE lane_id in(select lane_id from lane_info where inactive is null )
> AND date_part('hour', measurement_start) between 5 and 23
> AND date_part('day',measurement_start)=30
> GROUP BY lane_id,measurement_start,measurement_end,speed,volume,occupancy,quality,effective_date
> ORDER BY lane_id, measurement_start
>
> out of this only lane_id and mesaurement_start are indexed. This query
> will return around 10,000 rows. But it seems to be taking a long time
> to execute which doesnt make sense for a select statement. It doesnt
> make any sense to create index for every field we are gonna use in tne
> where clause.
> Isnt there any way we can improve the performance?

I'm guessing that adding an index for either
date_part('hour',measurement_start) or
date_part('day',measurement_start) or both would help.

What does explain analyze select ... (rest of query here) say?

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

[ODBC] Function sequence error when executing DELETE with 08.03.0200

Hello,

I'm trying to get the latest pgsql-odbc driver working with my database
creation app.

The following error occurs when a DELETE statement is executed:

12830016:S1010:[iODBC][Driver Manager]Function sequence error

I'm running pgsql-odbc 08.03.0200 against a PostgreSQL 8.2.3 database,
on Mac OS X Leopard using iODBC.

Any assistance would be appreciated.

Regards,

Nick

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

Re: [HACKERS] Location for pgstat.stat

Alvaro Herrera wrote:
> Magnus Hagander wrote:
>
>> Not sure. I guess my own personal concern would be how badly is
>> autovacuum affected by having to start off a blank set of stats? Any
>> other uses I have I think are capable of dealing with reset-to-zero states.
>
> Well, it doesn't :-) No database or table will be processed until stat
> entries are created, and then I think it will first wait until enough
> activity gathers to take any actions at all.

That's not actualliy not affected, but it does seem like it wouldn't be
a very big issue. If one table was just about to be vacuumed or
analyzed, this would just push it up to twice the threshold, right?

//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] A new take on the foot-gun meme

"Shane Ambler" <pgsql@Sheeky.Biz> writes:

> Robert Treat wrote:
>
>>> So is that a "golf club gun"?
>>
>> Careful what you wish for....
>> http://www.totallyabsurd.com/12gaugegolfclub.htm
>
> I reckon they watched Caddyshack (I think that was the one) and thought they
> could get the patent before someone actually tried selling them.

Surely a movie counts as "published"!?

--
Gregory Stark
EnterpriseDB

http://www.enterprisedb.com

Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training!

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

Re: [NOVICE] Automatic SQL command execution

--- On Fri, 6/27/08, Sean Davis <sdavis2@mail.nih.gov> wrote:

>> Postgresql doesn't have tools to do that directly. If
>> you are on
>> Linux or Unix, you can use cron; Windows probably has
>> something
>> similar to automate tasks.
>>

> I use nncron lite. Free and cron file compatible.

> http://www.nncron.ru/nncronlt/help/help.htm


> Lewis R Cunningham

> An Expert's Guide to Oracle Technology
> http://blogs.ittoolbox.com/oracle/guide/


> Postgres Forums
> http://postgres.enterprisedb.com/forum.do



Actually you can use PgAgent which comes packaged with PgAdmin III.
I've used it successfully on both windows and RedHat linux. I think it
works anywhere PostgreSQL works. The nice thing about PgAgent is that
you can see the status of jobs from the PgAdmin administrative tool and
trigger a manual run of a scheduled job from PgAdmin tool from anywhere.

http://www.pgadmin.org/docs/1.8/pgagent.html


Hope that helps,
Regina
-----------------------------------------
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.


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

[PERFORM] Select running slow on Postgres

Hi
I have a select statement that runs on a partition having say couple
million rows.
The tabel has indexes on two colums. However the query uses the
non-indexed colums too in its where clause.
For example:
SELECT lane_id,measurement_start,
measurement_end,speed,volume,occupancy,quality,effective_date
FROM tss.lane_data_06_08
WHERE lane_id in(select lane_id from lane_info where inactive is null )
AND date_part('hour', measurement_start) between 5 and 23
AND date_part('day',measurement_start)=30
GROUP BY lane_id,measurement_start,measurement_end,speed,volume,occupancy,quality,effective_date
ORDER BY lane_id, measurement_start

out of this only lane_id and mesaurement_start are indexed. This query
will return around 10,000 rows. But it seems to be taking a long time
to execute which doesnt make sense for a select statement. It doesnt
make any sense to create index for every field we are gonna use in tne
where clause.
Isnt there any way we can improve the performance?


Samantha

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

Re: [HACKERS] Location for pgstat.stat

Magnus Hagander wrote:

> Not sure. I guess my own personal concern would be how badly is
> autovacuum affected by having to start off a blank set of stats? Any
> other uses I have I think are capable of dealing with reset-to-zero states.

Well, it doesn't :-) No database or table will be processed until stat
entries are created, and then I think it will first wait until enough
activity gathers to take any actions at all.

--
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

Re: [HACKERS] Location for pgstat.stat

Tom Lane wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> Tom Lane wrote:
>>> Hmm ... that would almost certainly result in the stats being lost over
>>> a system shutdown. How much do we care?
>
>> Only for those who put it on a ramdrive. The default, unless you
>> move/sync it off, would still be the same as it is today. While not
>> perfect, the performance difference of going to a ramdrive might easily
>> be enough to offset that in some cases, I think.
>
> Well, what I was wondering about is whether it'd be worth adding logic
> to copy the file to/from a "safer" location at startup/shutdown.

Oh, I see. I should think more before I answer sometimes :-)

Not sure. I guess my own personal concern would be how badly is
autovacuum affected by having to start off a blank set of stats? Any
other uses I have I think are capable of dealing with reset-to-zero states.

//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] Fairly serious bug induced by latest guc enum changes

Magnus Hagander <magnus@hagander.net> writes:
> Not having looked at md.c (I confess...) but don't we have a problem in
> case we have closed the file without fsyncing it, and then change the
> fsync parameter?

Well, we don't promise to retroactively fsync stuff we didn't before;
and I wouldn't expect that to happen if I were changing the setting.
What I *would* expect is that the system immediately starts to act
according to the new setting, and that's not true as the code stands.

As you say, the whole thing is pretty dubious from a data safety
standpoint anyway. What I am concerned about here is people trying to
compare performance measurements under different settings, and not being
aware that the system's behavior doesn't change when they tell it to.

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

[planet] Testing...ignore..

--
Devrim GÜNDÜZ <devrim@gunduz.org>


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

Re: [HACKERS] Location for pgstat.stat

Magnus Hagander <magnus@hagander.net> writes:
> Tom Lane wrote:
>> Hmm ... that would almost certainly result in the stats being lost over
>> a system shutdown. How much do we care?

> Only for those who put it on a ramdrive. The default, unless you
> move/sync it off, would still be the same as it is today. While not
> perfect, the performance difference of going to a ramdrive might easily
> be enough to offset that in some cases, I think.

Well, what I was wondering about is whether it'd be worth adding logic
to copy the file to/from a "safer" location at startup/shutdown.

regards, tom lane

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

Re: [HACKERS] Fairly serious bug induced by latest guc enum changes

Tom Lane wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> Or are you talking about changing the variable "fsync"? If so, doesn't
>> "fsync=off" also change the behavior of other parts of the code, so it's
>> not just WAL, which means it'd be pretty unsafe *anyway* unless you
>> actually "sync" the disks, and not just fsync?
>
> No, because the other uses of it are controlling whether to issue
> fsync() calls dynamically. The use in get_sync_bit is the only one
> that sets persistent state. In fact md.c goes out of its way to ensure
> that changing fsync on the fly behaves as expected.

Not having looked at md.c (I confess...) but don't we have a problem in
case we have closed the file without fsyncing it, and then change the
fsync parameter?

Either way, I see your point, but I doubt it's worth getting upset over.
Funning with fsync=off in the first place is bad, and if it takes you
one WAL segment to "recover", I think that's acceptable...

//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] Fairly serious bug induced by latest guc enum changes

Magnus Hagander <magnus@hagander.net> writes:
> Or are you talking about changing the variable "fsync"? If so, doesn't
> "fsync=off" also change the behavior of other parts of the code, so it's
> not just WAL, which means it'd be pretty unsafe *anyway* unless you
> actually "sync" the disks, and not just fsync?

No, because the other uses of it are controlling whether to issue
fsync() calls dynamically. The use in get_sync_bit is the only one
that sets persistent state. In fact md.c goes out of its way to ensure
that changing fsync on the fly behaves as expected.

regards, tom lane

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

Re: [HACKERS] Access to localized_str_tolower()

On Jul 1, 2008, at 11:59, Tom Lane wrote:

> These are static --- that's why you can't get at them from outside
> the module.
>
> I think your best bet for an 8.3 version of citext is just to
> copy-and-paste a lot of code from HEAD.

Well, that's what I'd done already; I was just trying to make it
simpler. So, well, now I don't have to do anything. :-)

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: [INTERFACES] Where to find libpq++ ?

"rick richards" <rr047928@gmail.com> writes:
> Please advice on where to find libpq++.

If it's not on pgfoundry, you'll have to go digging in PG 7.2.x source
tarballs. In any case I think there's about 0 chance of finding it
prebuilt for any modern distro --- you'll have to compile from source.

regards, tom lane

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

Re: [HACKERS] Access to localized_str_tolower()

"David E. Wheeler" <david@kineticode.com> writes:
> From formatting.c in 8.3.1:
> static char *localized_str_toupper(char *buff);
> static char *localized_str_tolower(char *buff);

These are static --- that's why you can't get at them from outside
the module.

I think your best bet for an 8.3 version of citext is just to
copy-and-paste a lot of code from HEAD.

regards, tom lane

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

Re: [HACKERS] Location for pgstat.stat

Tom Lane wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> But pending that we have that, how about we just move it into it's own
>> subdirectory?
>> This would make it possible to symlink or mount that directory off to a
>> ramdrive (for example).
>
> Hmm ... that would almost certainly result in the stats being lost over
> a system shutdown. How much do we care?

Only for those who put it on a ramdrive. The default, unless you
move/sync it off, would still be the same as it is today. While not
perfect, the performance difference of going to a ramdrive might easily
be enough to offset that in some cases, I think.

//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] Fairly serious bug induced by latest guc enum changes

Tom Lane wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> Tom Lane wrote:
>>> Hmm ... or at least more or less fixed. Seems like there's no provision
>>> to close and reopen the file if enableFsync changes. Not sure if that's
>>> worth worrying about.
>
>> We didn't have that before either, did we?
>
> No, so I think it's a pre-existing bug.

Ok, at least I'm reading the code right.


>> We close it when the sync bit
>> changes, but not just if we change say between fsync() and fdatasync().
>> Is there any actual reason we'd want to close it?
>
> The point is that if you turn the fsync GUC on or off while using a wal
> sync mode that requires supplying an option flag to open(), then really
> you ought to close the WAL file and re-open it with the new correct
> option flags. The fact that we're not doing that implies that the
> effects of a change in fsync might not fully take effect until the next
> WAL segment is started. Whether this is worth fixing isn't real clear.

What scenario does it actually happen in, though? Doesn't the check:
if (get_sync_bit(sync_method) != get_sync_bit(new_sync_method))

take care of that? If the sync bit changed, we close the file?


Or are you talking about changing the variable "fsync"? If so, doesn't
"fsync=off" also change the behavior of other parts of the code, so it's
not just WAL, which means it'd be pretty unsafe *anyway* unless you
actually "sync" the disks, and not just fsync?

//Magnus


//Magnus

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