Re: Pgpool y postgresql 8.1

Hola Jaime,

2012/4/9 Jaime Casanova <jaime(at)2ndquadrant(dot)com>

> >
> > 2012/4/9 Lazaro Ruben Garcia Martinez <lgarciam(at)uci(dot)cu>
> 2012/4/9 Pablo Siciliano <pablo(dot)siciliano(at)gmail(dot)com>
> >
> > Hola Lazaro.
> >
> >
> >> Hola Pablo. Nunca he utilizado Pgpool-II con PostgreSQL 8.1, pero en la
> documentación oficial de Pgpool-
> >> II mencionan que la recuperación utilizando PITR, solo es posible a
> partir de la versión 8.2 de PostgreSQL.
> >> Yo te recomiendo revisar la documentación y te fijes en la sección
> ¨Online recovery with rsync¨.
> >
> > Te estas refiriendo a la documentacion de postgresql 8.1 o a la de
> pgpool II? Justamente en la
> > documentacion de postgresql es que me baso para hacer la pregunta. El
> tema que tengo es que el
> > directorio data es enorme como para hacer un rsync al momento de
> levantar un nodo.
> >
>
> ese pgpool es solo para alta disponibilidad, verdad? es decir no
> podras hacer balanceo de carga.
> es verdad que no hay pg_switch_xlog() pero podrias crear una tu. crea
> una funcion llamada asi que cree una tabla temporal y la llene con
> datos y borre la tabla (tendras que hacer calculos buenos para
> determinar cuando fue suficiente para generar un nuevo archivo de wal
> o simplemente calcular 16MB y de seguro que paso a un nuevo archivo).
> y luego ejecutas esa funcion cada X minutos en un cron
>
>
En principio no, la idea no es hacer balanceo de carga. Era una
alternativa, pero me parecio un poco extrema. Voy a estudiar mejor en
xlog.c como hacen el calculo en los sources de postgresql y tal vez siga
por ahi.

> >> Otra recomendación, y la más importante es que logres realizar una
> actualización de la versión de Postgres, porque esa es muy antigua.
> >>
> >
> > Si, lo se ... Como explique de antemano en mi post no esta dentro de
> ambito de desicion pedirle a mi
> > cliente que haga esa migracion, pero soy conciente de que es viejisima.
> De hecho, una de las primeras
> > cosas que hice cuando empece a trabajar con ellos fue sugerir esa
> migracion, a la cual se negaron porque
> > el equipo de desarrollo "no tenia tiempo" para revisar casts que en
> versiones mas nuevas de postgresql
> > deben ser explicitos.
> >
>
> yo que tu, los haría firmar un papel que diga que cuando pierdan
> información por usar una versión de postgres que no ha tenido soporte
> desde Nov 2010 (y que por lo tanto por mas de un año y medio no se ha
> hecho ningún intento (ni se hará) de corregir ninguna falla que pueda
> tener) tu no te responsabilizas y veras que como tu te lo tomas en
> serio ellos también lo harán.
>
>
Otra buena idea ...

> El día que algo falle todos descubrirán que por algún motivo fue culpa
> tuya, aunque tu hoy culpes a otros.
>
>
No culpo a nadie. Trabajo para terceros, que toman sus desiciones
empresariales acorde a montones de cosas que no vienen al caso y sobre las
que tampoco yo tengo control. Puedo llegar a cuestionar el tema y levantar
una alerta e incluso cubrirme, pero no mas que eso.

Agradezco tus comentarios, pero me parece que cabe aclarar que mis clientes
toman sus desiciones haciendo una evaluacion de proyectos coherente, aunque
haga ruido que tengan una version de postgresql tan vieja ... Y yo no suelo
tomar mis proyectos a la ligera. Este de hecho no es el caso, y ya habia
dado recomendaciones por escrito al respecto.

--
> Jaime Casanova www.2ndQuadrant.com
> Professional PostgreSQL: Soporte 24x7 y capacitación
>

Gracias por tu ayuda, Jaime.
Saludos.
Pablo.