Jaime Casanova [mailto:jcasa...@systemguards.com.ec] escribio:
> no he hecho la prueba pero no veo porque no se podria... por
> cierto, el puerto que indicas que usaste para pgbouncer en
> odbc es 6432, espero que solo sea un error en el mail...
> porque el puerto del pgbouncer es 6543
Tienes ra
2009/3/10 Alvaro Herrera :
>
>> por esto buscaba algun comando que verifique toda la base de datos
>> antes de ponerla operacional. al menos el ultimo vacuum analyze no me
>> informo de nada incorrecto.. pero es suficiente?
>
> No necesariamente. No es el proposito para el que existe. En version
On Tue, Mar 10, 2009 at 9:21 PM, Juan Luis Echeverria
wrote:
>
> Hola compañeros:
> He instalado PG-Bouncer para que sea el pool para una BD Postgres sobre un
> server FreeBSD. Al ejecutar desde un cliente WinXP "psql -h host -p 6543 -U
> user database" conecta bien. El problema es cuando lo hago
Hola compañeros:
He instalado PG-Bouncer para que sea el pool para una BD Postgres sobre un
server FreeBSD. Al ejecutar desde un cliente WinXP "psql -h host -p 6543 -U
user database" conecta bien. El problema es cuando lo hago por ODBC (psqlODBC
8.03) -siempre desde el cliente WinXP- al cambiar
Gabriel Ferro escribió:
>
> Como les comente hubo un problema en la alimentacion y el ubuntu
> estaba colgado y solo me quedo resetear, cuando arranco tuve estos
> problemas...
OK.
> por esto buscaba algun comando que verifique toda la base de datos
> antes de ponerla operacional. al menos el u
Como les comente hubo un problema en la alimentacion y el ubuntu estaba colgado
y solo me quedo resetear, cuando arranco tuve estos problemas...
por esto buscaba algun comando que verifique toda la base de datos antes de
ponerla operacional.
al menos el ultimo vacuum analyze no me informo de nad
Verifica si el usuario postgres tiene permisos en ese directorio.
Sino tiene los debidos permisos, no puedes usarlo.
El mar, 10-03-2009 a las 21:39 +, Edwin Quijada escribió:
> Estoy tratando de crear un nuevo tablespace en otro disco,SAN ,
> montandolo remotamente. Lo monte de la sigte manera
Edwin Quijada escribió:
> uranio:/mnt# mount -t cifs //x.x.x.x/db /mnt/DB
>
> uranio:/mnt# chown -R postgres.postgres /mnt/DB
Debes crear un directorio dentro de /mnt/DB (despues de montarlo
obviamente) y hacer el tablespace en el.
--
Alvaro Herrera http://planet.
Estoy tratando de crear un nuevo tablespace en otro disco,SAN , montandolo
remotamente. Lo monte de la sigte manera
uranio:/mnt# mount -t cifs //x.x.x.x/db /mnt/DB
uranio:/mnt# chown -R postgres.postgres /mnt/DB
uranio:/mnt# mount | grep /mnt/DB
//x.x.x.x./db on /mnt/DB type cifs (rw,ma
Emanuel Calvo Franco escribió:
> 2009/3/10 Gabriel Ferro :
> >
> > - Mensaje original
> >
> >> De: Gabriel Ferro
> >> Para: pgsql-es-ayuda@postgresql.org
> >> Enviado: martes 10 de marzo de 2009, 7:12:10
> >> Asunto: [pgsql-es-ayuda] Error en vacuum antes era error con update
> >>
> >>
>
2009/3/10 Gabriel Ferro :
>
> - Mensaje original
>
>> De: Gabriel Ferro
>> Para: pgsql-es-ayuda@postgresql.org
>> Enviado: martes 10 de marzo de 2009, 7:12:10
>> Asunto: [pgsql-es-ayuda] Error en vacuum antes era error con update
>>
>>
>> Pues luego de rehacer los indices ejecute un vacuu
- Mensaje original
> De: Gabriel Ferro
> Para: pgsql-es-ayuda@postgresql.org
> Enviado: martes 10 de marzo de 2009, 7:12:10
> Asunto: [pgsql-es-ayuda] Error en vacuum antes era error con update
>
>
> Pues luego de rehacer los indices ejecute un vacuum y me da
> ERROR: left link chang
Pues luego de rehacer los indices ejecute un vacuum y me da
ERROR: left link changed unexpectedly in block 45968 of index personas_pkey
que pacho diria mi nena?
personas_pkey es el indice de la clave primaria de la tabla personas (con un
campo serial)... me habra fallado y me asigno dos re
13 matches
Mail list logo
