Re: timestamp out of range

Tengo un problema con los timestamp, el caso es este:
tengo estos datos como varchar
"1984-06-14"
"1983-02-21"
"1989-06-13"
si les hago (trim(f_nac))::timestamp without time zone, me quedan
"1984-06-14 00:00:00"
"1999-12-31 -147768:00:00"
"1989-06-13 00:00:00"

el segundo caso deberia ser 1983-02-21 00:00:00 y la consulta da error por timestamp out of range
si uso cast(f_nac as date) aparentemente no tengo problemas, el caso es que la tabla tiene 2 millones de registros y este error empezo de un dia a otro y no tengo un patron es aleatoreo. y aparentemente esta pasando en otras tabla que tambien tiene fechas que algunas llegan a los 11 millones de registro.

Si alguien sabe a que se debe, desde ya agradecido

Guillermo Muñoz

Puedes pasar la salida de:

SELECT version()
para tener mas datos de tu Postgresql

SELECT current_setting('datestyle');

Para ver la configuracion de tu datestyle

Puedes mirar tambien la seccion:

8.5.1. Date/Time Input

en:

http://www.postgresql.org/docs/8.2/static/datatype-datetime.html
Espero que te sirva, fuerza!
--
§~^Calabaza^~§ from Villa Elisa, Paraguay

Perdon, era basico el dato

SELECT version()
"PostgreSQL 8.2.4 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 4.1.1
20070105 (Red Hat 4.1.1-52)"

SELECT current_setting('datestyle');
"ISO, MDY"

este ultimo no me gusta mucho

Saludos

----- Original Message -----
From: "Calabaza Calabaza" <calalinux(at)gmail(dot)com>
To: <pgsql-es-ayuda(at)postgresql(dot)org>
Sent: Wednesday, September 19, 2007 10:46 AM
Subject: Re: timestamp out of range

Puedes pasar la salida de:

SELECT version()
para tener mas datos de tu Postgresql

SELECT current_setting('datestyle');

Para ver la configuracion de tu datestyle

Puedes mirar tambien la seccion:

8.5.1. Date/Time Input

en:

http://www.postgresql.org/docs/8.2/static/datatype-datetime.html
Espero que te sirva, fuerza!
--
§~^Calabaza^~§ from Villa Elisa, Paraguay

--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.485 / Virus Database: 269.13.21/1012 - Release Date: 16/09/2007
06:32 p.m.

Te puedo mostrar la prueba que hice:
Ejecutando:

SELECT version()

SELECT current_setting('datestyle');

create table fechas (fecha varchar(10));

insert into fechas values('1984-06-14');
insert into fechas values('1983-02-21');
insert into fechas values('1989-06-13');

Select
fecha::timestamp without time zone
from fechas;

Estos fueron mis resultados:

"PostgreSQL 8.0.3 on i686-pc-mingw32, compiled by GCC gcc.exe (GCC)
3.4.2 (mingw-special)"

"ISO, MDY"

"1984-06-14 00:00:00"
"1983-02-21 00:00:00"
"1989-06-13 00:00:00"

No tengo un 8.2.4 a mano para probarlo, espero que te sirva.
--
§~^Calabaza^~§ from Villa Elisa, Paraguay

El 19/09/07, Calabaza Calabaza <calalinux(at)gmail(dot)com> escribió:
> Te puedo mostrar la prueba que hice:
...
>
> No tengo un 8.2.4 a mano para probarlo, espero que te sirva.

Usando la versión
PostgreSQL 8.2.4 on i686-pc-mingw32, compiled by GCC gcc.exe (GCC)
3.4.2 (mingw-special)

a mi me salen los mismos resultados.
--
Miguel Rodríguez Penabad

Lo siento Miguel, se me fue al privado, aqui para la lista:

El 19/09/07, Miguel Rodríguez Penabad <penabad(at)gmail(dot)com> escribió:
> El 19/09/07, Calabaza Calabaza <calalinux(at)gmail(dot)com> escribió:
> >
> > No tengo un 8.2.4 a mano para probarlo, espero que te sirva.
>
> Usando la versión
> PostgreSQL 8.2.4 on i686-pc-mingw32, compiled by GCC gcc.exe (GCC)
> 3.4.2 (mingw-special)
>
> a mi me salen los mismos resultados.

Hay alguien que quiera probar esto en un 8.2.4 para salir de la duda???

--
§~^Calabaza^~§ from Villa Elisa, Paraguay

El 19/09/07, Guillermo Muñoz <guillermo(dot)munoz(at)grupotekne(dot)com(dot)ar> escribió:
>
>
> Tengo un problema con los timestamp, el caso es este:
> tengo estos datos como varchar
> "1984-06-14"
> "1983-02-21"
> "1989-06-13"
> si les hago (trim(f_nac))::timestamp without time zone, me quedan

¿ cual es el tipo de f_nac (largo) ?

Si es una fecha de nacimiento, por que quieres pasar a timestamp,
necesitas la hora ?

> "1984-06-14 00:00:00"
> "1999-12-31 -147768:00:00"
> "1989-06-13 00:00:00"
>
> el segundo caso deberia ser 1983-02-21 00:00:00 y la consulta da error por
> timestamp out of range

¿ Si son fechas de nacimiento, por que deseas que sean timestamp ?

> si uso cast(f_nac as date) aparentemente no tengo problemas, el caso es que
> la tabla tiene 2 millones de registros y este error empezo de un dia a otro
> y no tengo un patron es aleatoreo. y aparentemente esta pasando en otras
> tabla que tambien tiene fechas que algunas llegan a los 11 millones de
> registro.

¿ Las fechas las guardas como varchar de que largo ?
¿ Que version de?

>
> Si alguien sabe a que se debe, desde ya agradecido
>
> Guillermo Muñoz
>
>

--
_________________________________
Solo soy una mente genial en un cuerpo

El 19/09/07, Miguel Rodríguez Penabad <penabad(at)gmail(dot)com> escribió:
> El 19/09/07, Calabaza Calabaza <calalinux(at)gmail(dot)com> escribió:
> >
> > Hay alguien que quiera probar esto en un 8.2.4 para salir de la duda???
>
> ¿No sirvo yo?
>
Claro que sí, pero es para ver si alguien mas tiene el mismo problema,
y entonces determinar si es un bug o que es lo que esta pasando...
--
§~^Calabaza^~§ from Villa Elisa, Paraguay

----- Original Message -----
From: "usuario anonimo" <opinante(dot)anonimo(at)gmail(dot)com>
To: "Guillermo Muñoz" <guillermo(dot)munoz(at)grupotekne(dot)com(dot)ar>
Cc: "PostgreSQL" <pgsql-es-ayuda(at)postgresql(dot)org>
Sent: Wednesday, September 19, 2007 11:41 AM
Subject: Re: [pgsql-es-ayuda] timestamp out of range

El 19/09/07, Guillermo Muñoz <guillermo(dot)munoz(at)grupotekne(dot)com(dot)ar> escribió:
>
>
> Tengo un problema con los timestamp, el caso es este:
> tengo estos datos como varchar
> "1984-06-14"
> "1983-02-21"
> "1989-06-13"
> si les hago (trim(f_nac))::timestamp without time zone, me quedan

>>¿ cual es el tipo de f_nac (largo) ?
**son character varying(10)

>>Si es una fecha de nacimiento, por que quieres pasar a timestamp,
>>necesitas la hora ?

**en realidad no, el tema es que son datos importados desde DBF. el tipo
date nos trajo muchos problemas por eso se decidio pasar a texto

> "1984-06-14 00:00:00"
> "1999-12-31 -147768:00:00"
> "1989-06-13 00:00:00"
>
> el segundo caso deberia ser 1983-02-21 00:00:00 y la consulta da error por
> timestamp out of range

>>¿ Si son fechas de nacimiento, por que deseas que sean timestamp ?
**por esto mismo que te comentaba, son datos dbf importados con kettle de
pentaho, que a todas las fecha las toma asi.

> si uso cast(f_nac as date) aparentemente no tengo problemas, el caso es
> que
> la tabla tiene 2 millones de registros y este error empezo de un dia a
> otro
> y no tengo un patron es aleatoreo. y aparentemente esta pasando en otras
> tabla que tambien tiene fechas que algunas llegan a los 11 millones de
> registro.

>>¿ Las fechas las guardas como varchar de que largo ?
**character varying(10)
>>¿ Que version de?
** version de postgres 8.2.4

>
> Si alguien sabe a que se debe, desde ya agradecido
>
> Guillermo Muñoz
>
>

--
_________________________________
Solo soy una mente genial en un cuerpo

--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.485 / Virus Database: 269.13.21/1012 - Release Date: 16/09/2007
06:32 p.m.

El 19/09/07, Calabaza Calabaza <calalinux(at)gmail(dot)com> escribió:
> El 19/09/07, Miguel Rodríguez Penabad <penabad(at)gmail(dot)com> escribió:
> > El 19/09/07, Calabaza Calabaza <calalinux(at)gmail(dot)com> escribió:
> > >
> > > Hay alguien que quiera probar esto en un 8.2.4 para salir de la duda???
> >
> > ¿No sirvo yo?
> >
> Claro que sí, pero es para ver si alguien mas tiene el mismo problema,
> y entonces determinar si es un bug o que es lo que esta pasando...

Por si acaso, que me estoy liando... en mi versión 8.2.4 cuando dije
"me salen los mismos resultados" me refería a que me salía lo mismo
que a ti en la versión 8.0.3, es decir, los datos correctos. Eso sí,
mi versión es de windows, no tengo acceso a la 8.2.4 en linux (todas
son 8.0.X), pero me extrañaría que fuese un bug sólo en la versión
compilada bajo linux.
--
Miguel Rodríguez Penabad

----- Original Message -----
From: "Miguel Rodríguez Penabad" <penabad(at)gmail(dot)com>
To: "Calabaza Calabaza" <calalinux(at)gmail(dot)com>
Cc: <pgsql-es-ayuda(at)postgresql(dot)org>
Sent: Wednesday, September 19, 2007 11:31 AM
Subject: Re: [pgsql-es-ayuda] timestamp out of range

El 19/09/07, Calabaza Calabaza <calalinux(at)gmail(dot)com> escribió:
> Te puedo mostrar la prueba que hice:
...
>
> No tengo un 8.2.4 a mano para probarlo, espero que te sirva.

Usando la versión
PostgreSQL 8.2.4 on i686-pc-mingw32, compiled by GCC gcc.exe (GCC)
3.4.2 (mingw-special)

a mi me salen los mismos resultados.

** de error o bien?
--
Miguel Rodríguez Penabad
--
TIP 9: visita nuestro canal de IRC #postgresql-es en irc.freenode.net

--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.485 / Virus Database: 269.13.21/1012 - Release Date: 16/09/2007
06:32 p.m.

el caso que plantee es uno de varios que me estan trayendo problemas.
cuando me da el error me transforma a esto "timestamp : 1999-12-31 -342432:00:00" y out of range.
inicialmente vacuum full parecia que lo solucionaba, pero ahora la misma consulta la ejecuto me da error y 2 minutos despues nada se ejecuta normalmente.
Lo que me queda, es que el motor este corrupto y tenga que hacer una reinstalacion del postgres
les parece logico esto?
haciendo un dump_all antes ¿no?
----- Original Message -----
From: Guillermo Muñoz
To: Miguel Rodríguez Penabad ; Calabaza Calabaza
Cc: pgsql-es-ayuda(at)postgresql(dot)org
Sent: Wednesday, September 19, 2007 11:55 AM
Subject: Re: [pgsql-es-ayuda] timestamp out of range

----- Original Message -----
From: "Miguel Rodríguez Penabad" <penabad(at)gmail(dot)com>
To: "Calabaza Calabaza" <calalinux(at)gmail(dot)com>
Cc: <pgsql-es-ayuda(at)postgresql(dot)org>
Sent: Wednesday, September 19, 2007 11:31 AM
Subject: Re: [pgsql-es-ayuda] timestamp out of range

El 19/09/07, Calabaza Calabaza <calalinux(at)gmail(dot)com> escribió:
> Te puedo mostrar la prueba que hice:
...
>
> No tengo un 8.2.4 a mano para probarlo, espero que te sirva.

Usando la versión
PostgreSQL 8.2.4 on i686-pc-mingw32, compiled by GCC gcc.exe (GCC)
3.4.2 (mingw-special)

a mi me salen los mismos resultados.

** de error o bien?
--
Miguel Rodríguez Penabad
--
TIP 9: visita nuestro canal de IRC #postgresql-es en irc.freenode.net

--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.485 / Virus Database: 269.13.21/1012 - Release Date: 16/09/2007
06:32 p.m.

--
TIP 7: no olvides aumentar la configuración del "free space map"

--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.485 / Virus Database: 269.13.21/1012 - Release Date: 16/09/2007 06:32 p.m.

El 19/09/07, Guillermo Muñoz <guillermo(dot)munoz(at)grupotekne(dot)com(dot)ar> escribió:
>
> el caso que plantee es uno de varios que me estan trayendo problemas.

Postea todos los problemas...

> cuando me da el error me transforma a esto "timestamp : 1999-12-31
> -342432:00:00" y out of range.

Esto es en alguna funcion en tu postgresql o cuando lo ejecutas desde
el cliente que utiliza tu DB???

> inicialmente vacuum full parecia que lo solucionaba, pero ahora la misma
> consulta la ejecuto me da error y 2 minutos despues

>nada se ejecuta
> normalmente.

A que te refieres con >>>nada se ejecuta normalmente<<<??
Postea lo que pruebas please.

> Lo que me queda, es que el motor este corrupto y tenga que hacer una
> reinstalacion del postgres
> les parece logico esto?

No, en absoluto...

> haciendo un dump_all antes ¿no?
>
Si urgente un dump_all por cualquier cosa!!!

Ah.. Alvaro alguna opinion??
--
§~^Calabaza^~§ from Villa Elisa, Paraguay

El 19/09/07, Calabaza Calabaza <calalinux(at)gmail(dot)com> escribió:
> El 19/09/07, Guillermo Muñoz <guillermo(dot)munoz(at)grupotekne(dot)com(dot)ar> escribió:
> >
> > el caso que plantee es uno de varios que me estan trayendo problemas.
>
> Postea todos los problemas...
>
> > cuando me da el error me transforma a esto "timestamp : 1999-12-31
> > -342432:00:00" y out of range.
>
> Esto es en alguna funcion en tu postgresql o cuando lo ejecutas desde
> el cliente que utiliza tu DB???
>
> > inicialmente vacuum full parecia que lo solucionaba, pero ahora la misma
> > consulta la ejecuto me da error y 2 minutos despues
>
> >nada se ejecuta
> > normalmente.
>
> A que te refieres con >>>nada se ejecuta normalmente<<<??
> Postea lo que pruebas please.
>
> > Lo que me queda, es que el motor este corrupto y tenga que hacer una
> > reinstalacion del postgres
> > les parece logico esto?
>
> No, en absoluto...

Yo me imagino que tiene fechas en distintos formatos a MDY de hecho
los ejemplo que muestra es YMD, yo sugiero que apliques un select que
te desplegué todos los valores de f_nac buscando formatos incorrecto
como por ejemplo un:

select f_nac, length(f_nac) from tu_tabla where (length(f_nac) < 10 or
length(f_nac) > 10)
-- si este select no arroja filas es que el problema debe estar en el formato.

Yo tengo una configuración similar a la que describes y no tengo
problemas de hecho configure mi server con date_style = "ISO, MDY"
como tu y funcionaron mis pruebas.

>
> > haciendo un dump_all antes ¿no?

No creo que sea problema de PostgreSQL sino que de tu data.

> >
> Si urgente un dump_all por cualquier cosa!!!

siempre se hace!!!

>
> Ah.. Alvaro alguna opinion??

La mitad de Chile esta con resaca(con el hachazo) y la otra mitad
sigue bebiendo :-)

> --
> §~^Calabaza^~§ from Villa Elisa, Paraguay
> --
> TIP 3: Si encontraste la respuesta a tu problema, publícala, otros te lo agradecerán
>

--
_________________________________
Solo soy una mente genial en un cuerpo

Los casos no los tengo detectados puntualmete (en general si, por eso planee el problema con f_nac), es basicamente en tablas con columnas time stamp cuando les aplico date(campo) o campo::time stamp. lo raro es que ejecuta las consultas y falla, un rato despues las vuelvo a ejecutar sin problemas (me retornan los datos).
para el caso puntual de f_nac todos los valores estan en YYYY-MM-DD y al hacer la conversion tengo ese problema.
Justamente ahora reinicie el servidor, cambie algunos parametros de la configuracion:
datestyle='iso, YMD'
subi la memoria de trabajo 700MB
subi el cache_size a 900MB
y reinicie postgres

hice un vacuum de las tablas a consultar y hace 2 horas que esta corriendo, hasta que vuelva el problema
el seridor en el que estoy trabajando es:
Hp proliant G4, doble dual core y 8 GB de ram con CentOs 5

Saludos
----- Original Message -----
From: usuario anonimo
To: Calabaza Calabaza
Cc: pgsql-es-ayuda(at)postgresql(dot)org
Sent: Wednesday, September 19, 2007 1:35 PM
Subject: Re: [pgsql-es-ayuda] timestamp out of range

El 19/09/07, Calabaza Calabaza <calalinux(at)gmail(dot)com> escribió:
> El 19/09/07, Guillermo Muñoz <guillermo(dot)munoz(at)grupotekne(dot)com(dot)ar> escribió:
> >
> > el caso que plantee es uno de varios que me estan trayendo problemas.
>
> Postea todos los problemas...
>
> > cuando me da el error me transforma a esto "timestamp : 1999-12-31
> > -342432:00:00" y out of range.
>
> Esto es en alguna funcion en tu postgresql o cuando lo ejecutas desde
> el cliente que utiliza tu DB???
>
> > inicialmente vacuum full parecia que lo solucionaba, pero ahora la misma
> > consulta la ejecuto me da error y 2 minutos despues
>
> >nada se ejecuta
> > normalmente.
>
> A que te refieres con >>>nada se ejecuta normalmente<<<??
> Postea lo que pruebas please.
>
> > Lo que me queda, es que el motor este corrupto y tenga que hacer una
> > reinstalacion del postgres
> > les parece logico esto?
>
> No, en absoluto...

Yo me imagino que tiene fechas en distintos formatos a MDY de hecho
los ejemplo que muestra es YMD, yo sugiero que apliques un select que
te desplegué todos los valores de f_nac buscando formatos incorrecto
como por ejemplo un:

select f_nac, length(f_nac) from tu_tabla where (length(f_nac) < 10 or
length(f_nac) > 10)
-- si este select no arroja filas es que el problema debe estar en el formato.

Yo tengo una configuración similar a la que describes y no tengo
problemas de hecho configure mi server con date_style = "ISO, MDY"
como tu y funcionaron mis pruebas.

>
> > haciendo un dump_all antes ¿no?

No creo que sea problema de PostgreSQL sino que de tu data.

> >
> Si urgente un dump_all por cualquier cosa!!!

siempre se hace!!!

>
> Ah.. Alvaro alguna opinion??

La mitad de Chile esta con resaca(con el hachazo) y la otra mitad
sigue bebiendo :-)

> --
> §~^Calabaza^~§ from Villa Elisa, Paraguay
> --
> TIP 3: Si encontraste la respuesta a tu problema, publícala, otros te lo agradecerán
>

--
_________________________________
Solo soy una mente genial en un cuerpo
--
TIP 5: ¿Has leído nuestro extenso FAQ?
http://www.postgresql.org/docs/faqs.FAQ.html

--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.485 / Virus Database: 269.13.21/1012 - Release Date: 16/09/2007 06:32 p.m.

Perdonen que retome el tema, pero ahora es con el pg_dump

pg_dump: reading dependency data
pg_dump: saving encoding = UTF8
pg_dump: saving standard_conforming_strings = off
pg_dump: saving database definition
pg_dump: SQL command failed
pg_dump: Error message from server: ERROR: timestamp out of range
pg_dump: The command was: FETCH 100 FROM _pg_dump_cursor
pg_dump: *** aborted because of error

----- Original Message -----
From: Calabaza Calabaza
To: pgsql-es-ayuda(at)postgresql(dot)org
Sent: Wednesday, September 19, 2007 11:21 AM
Subject: Re: [pgsql-es-ayuda] timestamp out of range

Te puedo mostrar la prueba que hice:
Ejecutando:

SELECT version()

SELECT current_setting('datestyle');

create table fechas (fecha varchar(10));

insert into fechas values('1984-06-14');
insert into fechas values('1983-02-21');
insert into fechas values('1989-06-13');

Select
fecha::timestamp without time zone
from fechas;

Estos fueron mis resultados:

"PostgreSQL 8.0.3 on i686-pc-mingw32, compiled by GCC gcc.exe (GCC)
3.4.2 (mingw-special)"

"ISO, MDY"

"1984-06-14 00:00:00"
"1983-02-21 00:00:00"
"1989-06-13 00:00:00"

No tengo un 8.2.4 a mano para probarlo, espero que te sirva.
--
§~^Calabaza^~§ from Villa Elisa, Paraguay
--
TIP 8: explain analyze es tu amigo

--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.485 / Virus Database: 269.13.21/1012 - Release Date: 16/09/2007 06:32 p.m.

Guillermo Muñoz escribió:
> Tengo un problema con los timestamp, el caso es este:
> tengo estos datos como varchar
> "1984-06-14"
> "1983-02-21"
> "1989-06-13"
> si les hago (trim(f_nac))::timestamp without time zone, me quedan
> "1984-06-14 00:00:00"
> "1999-12-31 -147768:00:00"
> "1989-06-13 00:00:00"
>
> el segundo caso deberia ser 1983-02-21 00:00:00 y la consulta da error
> por timestamp out of range si uso cast(f_nac as date) aparentemente
> no tengo problemas, el caso es que la tabla tiene 2 millones de
> registros y este error empezo de un dia a otro y no tengo un patron es
> aleatoreo. y aparentemente esta pasando en otras tabla que tambien
> tiene fechas que algunas llegan a los 11 millones de registro.

Uff. Guardar fechas en campos varchar es pesima idea, precisamente por
problemas como este.

Tengo la sensacion de que hay alguna conversion que se esta haciendo de
una manera inesperada. Por favor envia la salida de lo siguiente:

show datestyle;
show integer_datetimes;

select ctid, '{' || fnac || '}', trim(fnac),
trim(f_nac)::timestamp without time zone
from tabla where fnac like '1983%';

Lo que quiero saber es si esa fecha de 1999 que tiene las horas erroneas
equivale a la de 1983-02-21.

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

Alvaro
Estos datos son importados desde DBF en texto con formato YYYY-MM-DD a una base de datos que tiene los campos character varying(10)
despues se pasan a otra base en el mismo servidor, convirtiendolos a date (antes estaban como timestamp)
case when trim(f_nac)='0-00-00' then null else cast(f_nac as date) end as f_nac --falla
case when trim(f_nac)='0-00-00' then null else f_nac::date end as f_nac --falla
esta es la conversion, la fecha '0-00-00' es la nula. ahora estoy usando cast(f_nac as date) pero ya probe con f_nac::date y tampoco funciono.
en las fecha no hay valores extraños: o es una fecha o '0-00-00'.
Otro dato, el error es aleatoreo. ejecutas la consulta tira el error dos segundos despues ejecuta bien y ni hablar si lo hago en otra pc.

Cumplo con pasarte lo que me pedis:
Estructura de los campos
f_nac character varying(10),
show datestyle;
"ISO, MDY"
show integer_datetimes;
"off"
select ctid, '{' || f_nac || '}', trim(f_nac),
trim(f_nac)::timestamp without time zone,trim(f_nac)::date
from afi301 where f_nac like '1983%';

1ra ejecucion:
(200,3);"{1983-04-05}";"1983-04-05";"1983-04-05 00:00:00";"1983-04-05"
(200,18);"{1983-09-12}";"1983-09-12";"1999-12-31 -142896:00:00";"1983-09-12"
(201,16);"{1983-08-23}";"1983-08-23";"1983-08-23 00:00:00";"1983-08-23"
(202,9);"{1983-06-07}";"1983-06-07";"1983-06-07 00:00:00";"1983-06-07"

el primer registro sale en la posicion (fila) 99 (200,18)

2da ejecucion:
la vuelvo a ejecutar
(200,3);"{1983-04-05}";"1983-04-05";"1983-04-05 00:00:00";"1983-04-05"
(200,18);"{1983-09-12}";"1983-09-12";"1983-09-12 00:00:00";"1983-09-12"
(201,16);"{1983-08-23}";"1983-08-23";"1983-08-23 00:00:00";"1983-08-23"

ahora esta bien el registro de la fila 99 (200,18), pero ahora el primer registro roto esta en la fila 135 (274,16)

(274,5);"{1983-01-27}";"1983-01-27";"1983-01-27 00:00:00";"1983-01-27"
(274,16);"{1983-01-20}";"1983-01-20";"1999-12-31 -148536:00:00";"1983-01-20"
(275,2);"{1983-05-22}";"1983-05-22";"1983-05-22 00:00:00";"1983-05-22"

Como explique no tengo un patron y la unica documentacion que hay en postgres es que son registros corruptos. pero ya pase vacuum full ,analize y nada, borre indices porque es una tabla de 2 millones de resitros

Saludos
Guillermo Muñoz

----- Original Message -----
From: Alvaro Herrera
To: Guillermo Muñoz
Cc: pgsql-es-ayuda(at)postgresql(dot)org
Sent: Thursday, September 20, 2007 9:19 PM
Subject: Re: [pgsql-es-ayuda] timestamp out of range

Guillermo Muñoz escribió:
> Tengo un problema con los timestamp, el caso es este:
> tengo estos datos como varchar
> "1984-06-14"
> "1983-02-21"
> "1989-06-13"
> si les hago (trim(f_nac))::timestamp without time zone, me quedan
> "1984-06-14 00:00:00"
> "1999-12-31 -147768:00:00"
> "1989-06-13 00:00:00"
>
> el segundo caso deberia ser 1983-02-21 00:00:00 y la consulta da error
> por timestamp out of range si uso cast(f_nac as date) aparentemente
> no tengo problemas, el caso es que la tabla tiene 2 millones de
> registros y este error empezo de un dia a otro y no tengo un patron es
> aleatoreo. y aparentemente esta pasando en otras tabla que tambien
> tiene fechas que algunas llegan a los 11 millones de registro.

Uff. Guardar fechas en campos varchar es pesima idea, precisamente por
problemas como este.

Tengo la sensacion de que hay alguna conversion que se esta haciendo de
una manera inesperada. Por favor envia la salida de lo siguiente:

show datestyle;
show integer_datetimes;

select ctid, '{' || fnac || '}', trim(fnac),
trim(f_nac)::timestamp without time zone
from tabla where fnac like '1983%';

Lo que quiero saber es si esa fecha de 1999 que tiene las horas erroneas
equivale a la de 1983-02-21.

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

--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.485 / Virus Database: 269.13.21/1012 - Release Date: 16/09/2007 06:32 p.m.

Guillermo Muñoz escribió:

> Estructura de los campos
> f_nac character varying(10),
> show datestyle;
> "ISO, MDY"
> show integer_datetimes;
> "off"
> select ctid, '{' || f_nac || '}', trim(f_nac),
> trim(f_nac)::timestamp without time zone,trim(f_nac)::date
> from afi301 where f_nac like '1983%';
>
> 1ra ejecucion:
> (200,3);"{1983-04-05}";"1983-04-05";"1983-04-05 00:00:00";"1983-04-05"
> (200,18);"{1983-09-12}";"1983-09-12";"1999-12-31 -142896:00:00";"1983-09-12"
> (201,16);"{1983-08-23}";"1983-08-23";"1983-08-23 00:00:00";"1983-08-23"
> (202,9);"{1983-06-07}";"1983-06-07";"1983-06-07 00:00:00";"1983-06-07"

Hmm, ok. ¿Puedes reproducir este problema si haces la consulta
directamente en psql? Porque me da la impresión de que estás usando
ODBC o algo así.

La pregunta es debido a que tengo mis dudas si el bug está en Postgres o
bien es un problema del driver ODBC, o el driver que sea.

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

Hola..

Me pueden ayudar a configurar al pgadmin a informix,, cuales son los
parámetros...

Gracias

Jimmy Lopez
-----Mensaje original-----
De: Alvaro Herrera [mailto:alvherre(at)commandprompt(dot)com]
Enviado el: Viernes, 21 de Septiembre de 2007 02:29 p.m.
Para: Guillermo Muñoz
CC: pgsql-es-ayuda(at)postgresql(dot)org
Asunto: Re: [pgsql-es-ayuda] timestamp out of range

Guillermo Muñoz escribió:

> Estructura de los campos
> f_nac character varying(10),
> show datestyle;
> "ISO, MDY"
> show integer_datetimes;
> "off"
> select ctid, '{' || f_nac || '}', trim(f_nac),
> trim(f_nac)::timestamp without time zone,trim(f_nac)::date
> from afi301 where f_nac like '1983%';
>
> 1ra ejecucion:
> (200,3);"{1983-04-05}";"1983-04-05";"1983-04-05 00:00:00";"1983-04-05"
> (200,18);"{1983-09-12}";"1983-09-12";"1999-12-31
-142896:00:00";"1983-09-12"
> (201,16);"{1983-08-23}";"1983-08-23";"1983-08-23 00:00:00";"1983-08-23"
> (202,9);"{1983-06-07}";"1983-06-07";"1983-06-07 00:00:00";"1983-06-07"

Hmm, ok. ¿Puedes reproducir este problema si haces la consulta
directamente en psql? Porque me da la impresión de que estás usando
ODBC o algo así.

La pregunta es debido a que tengo mis dudas si el bug está en Postgres o
bien es un problema del driver ODBC, o el driver que sea.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
TIP 1: para suscribirte y desuscribirte, visita
http://archives.postgresql.org/pgsql-es-ayuda

Internal Virus Database is out-of-date.
Checked by AVG Free Edition.
Version: 7.5.485 / Virus Database: 269.13.16/1005 - Release Date: 13/09/2007
11:45 a.m.

Internal Virus Database is out-of-date.
Checked by AVG Free Edition.
Version: 7.5.485 / Virus Database: 269.13.16/1005 - Release Date: 13/09/2007
11:45 a.m.

Te adjunto el link de la documentacion de pgadmin de la compatibilidad con informix

http://pgadmin.org/docs/1.6/pg/ecpg-informix-compat.html

espero te sirva
Saludos
----- Original Message -----
From: Jimmy Lopez
To: 'Alvaro Herrera' ; 'Guillermo Muñoz'
Cc: pgsql-es-ayuda(at)postgresql(dot)org
Sent: Friday, September 21, 2007 4:34 PM
Subject: RE: [pgsql-es-ayuda] timestamp out of range

Hola..

Me pueden ayudar a configurar al pgadmin a informix,, cuales son los
parámetros...

Gracias

Jimmy Lopez
-----Mensaje original-----
De: Alvaro Herrera [mailto:alvherre(at)commandprompt(dot)com]
Enviado el: Viernes, 21 de Septiembre de 2007 02:29 p.m.
Para: Guillermo Muñoz
CC: pgsql-es-ayuda(at)postgresql(dot)org
Asunto: Re: [pgsql-es-ayuda] timestamp out of range

Guillermo Muñoz escribió:

> Estructura de los campos
> f_nac character varying(10),
> show datestyle;
> "ISO, MDY"
> show integer_datetimes;
> "off"
> select ctid, '{' || f_nac || '}', trim(f_nac),
> trim(f_nac)::timestamp without time zone,trim(f_nac)::date
> from afi301 where f_nac like '1983%';
>
> 1ra ejecucion:
> (200,3);"{1983-04-05}";"1983-04-05";"1983-04-05 00:00:00";"1983-04-05"
> (200,18);"{1983-09-12}";"1983-09-12";"1999-12-31
-142896:00:00";"1983-09-12"
> (201,16);"{1983-08-23}";"1983-08-23";"1983-08-23 00:00:00";"1983-08-23"
> (202,9);"{1983-06-07}";"1983-06-07";"1983-06-07 00:00:00";"1983-06-07"

Hmm, ok. ¿Puedes reproducir este problema si haces la consulta
directamente en psql? Porque me da la impresión de que estás usando
ODBC o algo así.

La pregunta es debido a que tengo mis dudas si el bug está en Postgres o
bien es un problema del driver ODBC, o el driver que sea.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
TIP 1: para suscribirte y desuscribirte, visita
http://archives.postgresql.org/pgsql-es-ayuda

Internal Virus Database is out-of-date.
Checked by AVG Free Edition.
Version: 7.5.485 / Virus Database: 269.13.16/1005 - Release Date: 13/09/2007
11:45 a.m.

Internal Virus Database is out-of-date.
Checked by AVG Free Edition.
Version: 7.5.485 / Virus Database: 269.13.16/1005 - Release Date: 13/09/2007
11:45 a.m.

--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.485 / Virus Database: 269.13.28/1021 - Release Date: 21/09/2007 02:02 p.m.

Alvaro:
En cuanto disponga de datos te paso la misma consulta por psql, la estoy sacando con el pgadmin

ahora me sale otro error cuando hago un pg_dump, porque empece a limpiar tablas que podian tener algun dato corrupto y el pg_dump avanzo mas pero cambio el error que me tira:

pg_dump: Error message from server: ERROR: cache lookup failed for index 104251
pg_dump: The command was: SELECT t.tableoid, t.oid, t.relname as indexname, pg_catalog.pg_get_indexdef(i.indexrelid) as indexdef, t.relnatts as indnkeys, i.indkey, i.indisclustered, c.contype, c.conname, c.tableoid as contableoid, c.oid as conoid, (SELECT spcname FROM pg_catalog.pg_tablespace s WHERE s.oid = t.reltablespace) as tablespace, array_to_string(t.reloptions, ', ') as options FROM pg_catalog.pg_index i JOIN pg_catalog.pg_class t ON (t.oid = i.indexrelid) LEFT JOIN pg_catalog.pg_depend d ON (d.classid = t.tableoid AND d.objid = t.oid AND d.deptype = 'i') LEFT JOIN pg_catalog.pg_constraint c ON (d.refclassid = c.tableoid AND d.refobjid = c.oid) WHERE i.indrelid = '36041'::pg_catalog.oid ORDER BY indexname
pg_dump: *** aborted because of error

que significa, esta corto de cache?
te comento, restaure la configuracion original de la instalacion
shared_buffers=32MB
max_fsm_pages=204800 y el log me esta pidiendo el doble

estoy en un servidor de 8 GB de ram, 4 discos de 72 GB con un raid 3+1 (espejado). lo puedo tunear bastante, pero cuando lo hice los procesos llegaban a 3GB y saltaban por out of memory.
(a los procesos les digo a funciones de carga)
te paso el dato por si tiene que ver

Saludos
Guillermo Muñoz
----- Original Message -----
From: Alvaro Herrera
To: Guillermo Muñoz
Cc: pgsql-es-ayuda(at)postgresql(dot)org
Sent: Friday, September 21, 2007 4:29 PM
Subject: Re: [pgsql-es-ayuda] timestamp out of range

Guillermo Muñoz escribió:

> Estructura de los campos
> f_nac character varying(10),
> show datestyle;
> "ISO, MDY"
> show integer_datetimes;
> "off"
> select ctid, '{' || f_nac || '}', trim(f_nac),
> trim(f_nac)::timestamp without time zone,trim(f_nac)::date
> from afi301 where f_nac like '1983%';
>
> 1ra ejecucion:
> (200,3);"{1983-04-05}";"1983-04-05";"1983-04-05 00:00:00";"1983-04-05"
> (200,18);"{1983-09-12}";"1983-09-12";"1999-12-31 -142896:00:00";"1983-09-12"
> (201,16);"{1983-08-23}";"1983-08-23";"1983-08-23 00:00:00";"1983-08-23"
> (202,9);"{1983-06-07}";"1983-06-07";"1983-06-07 00:00:00";"1983-06-07"

Hmm, ok. ¿Puedes reproducir este problema si haces la consulta
directamente en psql? Porque me da la impresión de que estás usando
ODBC o algo así.

La pregunta es debido a que tengo mis dudas si el bug está en Postgres o
bien es un problema del driver ODBC, o el driver que sea.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
TIP 1: para suscribirte y desuscribirte, visita http://archives.postgresql.org/pgsql-es-ayuda

--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.485 / Virus Database: 269.13.28/1021 - Release Date: 21/09/2007 02:02 p.m.

Guillermo Muñoz escribió:
> Alvaro:
> En cuanto disponga de datos te paso la misma consulta por psql, la estoy sacando con el pgadmin
>
> ahora me sale otro error cuando hago un pg_dump, porque empece a limpiar tablas que podian tener algun dato corrupto y el pg_dump avanzo mas pero cambio el error que me tira:
>
> pg_dump: Error message from server: ERROR: cache lookup failed for index 104251

Hummm, esto tiene pinta de problema mas serio. Quizas el hardware esta
fallando por algun motivo ... disco malo, quizas ram mala? Fijate en el
log del sistema operativo; hay algo raro? Mira tambien los mensajes de
SMART del disco. Si puedes, baja el servicio por unas horas y dejale
corriendo memtest86. Tambien prueba dejandole cpuburn corriendo unas
horas. En hardware que este bueno, no deberia pasar nada, pero si es
limitrofe y falla en condiciones extremas, es posible que arroje algun
error, en cuyo caso deberias cambiarlo.

> que significa, esta corto de cache?
> te comento, restaure la configuracion original de la instalacion
> shared_buffers=32MB
> max_fsm_pages=204800

No, el mensaje de "cache lookup failed" no tiene nada que ver con el
tamaño del cache.

> y el log me esta pidiendo el doble

A que te refieres? No has mostrado ningun error que pueda tener que ver
con eso.

> estoy en un servidor de 8 GB de ram, 4 discos de 72 GB con un raid 3+1
> (espejado). lo puedo tunear bastante, pero cuando lo hice los procesos
> llegaban a 3GB y saltaban por out of memory.
> (a los procesos les digo a funciones de carga)
> te paso el dato por si tiene que ver

Quizas el work_mem es demasiado alto? No tiene nada que ver con lo de
arriba en todo caso.

Raid 3+1 es lo mas raro que he escuchado. Lo mas recomendable para un
servidor de datos es 1+0.

--
Alvaro Herrera Valdivia, Chile ICBM: S 39º 49' 18.1", W 73º 13' 56.4"
"Las navajas y los monos deben estar siempre distantes" (Germán Poo)

> Guillermo Muñoz escribió:
>> Alvaro:
>> En cuanto disponga de datos te paso la misma consulta por psql, la estoy
>> sacando con el pgadmin
>>
>> ahora me sale otro error cuando hago un pg_dump, porque empece a limpiar
>> tablas que podian tener algun dato corrupto y el pg_dump avanzo mas pero
>> cambio el error que me tira:
>>
>> pg_dump: Error message from server: ERROR: cache lookup failed for index
>> 104251
>
> Hummm, esto tiene pinta de problema mas serio. Quizas el hardware esta
> fallando por algun motivo ... disco malo, quizas ram mala? Fijate en el
> log del sistema operativo; hay algo raro? Mira tambien los mensajes de
> SMART del disco. Si puedes, baja el servicio por unas horas y dejale
> corriendo memtest86. Tambien prueba dejandole cpuburn corriendo unas
> horas. En hardware que este bueno, no deberia pasar nada, pero si es
> limitrofe y falla en condiciones extremas, es posible que arroje algun
> error, en cuyo caso deberias cambiarlo.

y asi fue, esta mañana el servidor estaba tirando errores de inode y no
respondia ni siquiera a la consola. se hizo el fsck de la particion con un
livecd y se pudo acceder a los archivos.
se levanto la base de datos, pero el pg_dump siguio tirando errores con las
fecha.
el tema es ¿que tan confiable queda el servidor despues de este problema?.
antes de la ecatombe, se instalo una placa scii para la unidad de backup.

Saludos
Guillermo Muñoz

>
>
>> que significa, esta corto de cache?
>> te comento, restaure la configuracion original de la instalacion
>> shared_buffers=32MB
>> max_fsm_pages=204800
>
> No, el mensaje de "cache lookup failed" no tiene nada que ver con el
> tamaño del cache.
>
>> y el log me esta pidiendo el doble
>
> A que te refieres? No has mostrado ningun error que pueda tener que ver
> con eso.
>
>> estoy en un servidor de 8 GB de ram, 4 discos de 72 GB con un raid 3+1
>> (espejado). lo puedo tunear bastante, pero cuando lo hice los procesos
>> llegaban a 3GB y saltaban por out of memory.
>> (a los procesos les digo a funciones de carga)
>> te paso el dato por si tiene que ver
>
> Quizas el work_mem es demasiado alto? No tiene nada que ver con lo de
> arriba en todo caso.
>
> Raid 3+1 es lo mas raro que he escuchado. Lo mas recomendable para un
> servidor de datos es 1+0.
>
> --
> Alvaro Herrera Valdivia, Chile ICBM: S 39º 49' 18.1", W 73º 13'
> 56.4"
> "Las navajas y los monos deben estar siempre distantes" (Germán Poo)
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.485 / Virus Database: 269.13.28/1021 - Release Date:
> 21/09/2007 02:02 p.m.
>
>

Guillermo Muñoz escribió:

> y asi fue, esta mañana el servidor estaba tirando errores de inode y no
> respondia ni siquiera a la consola. se hizo el fsck de la particion con un
> livecd y se pudo acceder a los archivos.
> se levanto la base de datos, pero el pg_dump siguio tirando errores con las
> fecha.
> el tema es ¿que tan confiable queda el servidor despues de este problema?.
> antes de la ecatombe, se instalo una placa scii para la unidad de backup.

Bien poco.

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