Re: Comportamiento raro en pg_xlog.

Jaime,
Muchas gracias por responderme.
Entiendo lo que me decis, pero lo loco es que los wal que secuencia
posterior siguen apareciendo con regularidad.
Fijate el estado ahora, un par de horas después del que mandé en el mail
original.

295 oct 28 22:01 0000000100000146000000D2.00000020.backup
16777216 oct 29 11:46 00000001000001470000000A
16777216 oct 29 03:31 00000001000001470000000B
16777216 oct 29 03:46 00000001000001470000000C
16777216 oct 29 04:01 00000001000001470000000D
16777216 oct 29 04:16 00000001000001470000000E
16777216 oct 29 04:31 00000001000001470000000F
16777216 oct 29 04:46 000000010000014700000010
16777216 oct 29 05:01 000000010000014700000011
16777216 oct 29 05:16 000000010000014700000012
16777216 oct 29 05:31 000000010000014700000013
16777216 oct 29 05:46 000000010000014700000014
16777216 oct 29 06:01 000000010000014700000015
16777216 oct 29 06:16 000000010000014700000016
16777216 oct 29 06:31 000000010000014700000017
16777216 oct 29 06:46 000000010000014700000018
16777216 oct 29 07:01 000000010000014700000019
16777216 oct 29 07:16 00000001000001470000001A
16777216 oct 29 07:31 00000001000001470000001B
16777216 oct 29 07:46 00000001000001470000001C
16777216 oct 29 08:01 00000001000001470000001D
16777216 oct 29 08:16 00000001000001470000001E
16777216 oct 29 08:31 00000001000001470000001F
16777216 oct 29 08:46 000000010000014700000020
16777216 oct 29 09:01 000000010000014700000021
16777216 oct 29 09:16 000000010000014700000022
16777216 oct 29 09:31 000000010000014700000023
16777216 oct 29 09:46 000000010000014700000024
16777216 oct 29 10:01 000000010000014700000025
16777216 oct 29 10:16 000000010000014700000026
16777216 oct 29 10:31 000000010000014700000027
16777216 oct 29 10:46 000000010000014700000028
16777216 oct 29 11:01 000000010000014700000029
16777216 oct 29 11:16 00000001000001470000002A
16777216 oct 29 11:31 00000001000001470000002B
94 oct 29 11:46 archive_status/

0 oct 28 22:01 0000000100000146000000D2.00000020.backup.done
0 oct 29 11:46 00000001000001470000000A.done

postgres=# select pg_current_xlog_location();
pg_current_xlog_location
--------------------------
147/B001E40
(1 fila)

postgres=# select pg_xlogfile_name('147/B001E40');
pg_xlogfile_name
--------------------------
00000001000001470000000B
(1 fila)

Se crearon por ejemplo el 1470000000A (que entiendo es "por donde va" el
motor), pero también se crearon 28, 29, 2A, 2B. Fijate en la fecha de
creación de estos archivos.
Tal vez yo no estoy entendiendo bien como funciona, pero no es raro que,
pongamosle entre las 11:30 y las 11:47 se hallan generado DOS segmentos del
WAL con numeros que corresponden a secuencias distintas, para este caso
(00000001000001470000000A y 00000001000001470000002B). A medida que pasa el
tiempo siguen apareciendo wals consecutivos a partir de 0A y también a
partir de 2B...

En relación a lo otro que me comentas, efectivamente 15 minutos es lo que
tengo puesto en checkpoint_timeout; si le subo a 30 minutos; cual sería el
costo? digo, que problema podría tener? o bien; habría algún motivo para
dejarlo en 15?

Desde ya muchas gracias por la info.
Es la primera vez que consulta por una lista, disculpá si soy improcedente

Saludos.
Federico.

El 29 de octubre de 2015, 11:33, Jaime Casanova <
jaime(dot)casanova(at)2ndquadrant(dot)com> escribió:

> 2015-10-29 8:10 GMT-05:00 Federico Pascual <federico(dot)pascual(at)gmail(dot)com>:
> >
> > postgres=# select pg_current_xlog_location();
> > -[ RECORD 1 ]------------+------------
> > pg_current_xlog_location | 147/2004020
> >
>
> Aquí postgres te dice cual es el segmento de WAL que se esta usando
> actualmente.
>
> cgg=# select pg_xlogfile_name('147/2004020');
> pg_xlogfile_name
> --------------------------
> 000000010000014700000002
> (1 fila)
>
>
> y no hay evidencia de que postgres tenga conocimiento de otra
> secuencia como sugieres
>
> >
> > Si se fijan, 14700000002 se creo a las 09:41; el próximo será
> 14700000003,
> > pero este archivo ya existe creado antes a las 01:31.
>
> eso es porque estos son segmentos viejos listos para reutilizar,
> postgres conserva los segmentos necesarios para dos checkpoint atras
> por lo que cada vez que termina un checkpoint tiene segmentos que ya
> no le sirven (los que en ese momento serían el 3er checkpoint hacia
> atras) esos segmentos no los borra sino que los renombra para usarlos
> en el futuro. La razón de hacer esto es que así no necesita crear un
> archivo de 16mb en un apuro, sino que cuando empiece con el
> 000000010000014700000003 el archivo ya existirá y solo debe escribir
> en el.
>
> este comportamiento es completamente normal.
>
> Evidencias de que esto es asi?
> mira el valor registrado por log_checkpoints como "recycled"
>
> por cierto, yo diria que tus checkpoints estan ocurriendo con
> demasiada frecuencia, cada archivo tiene una separacion de 15min (que
> supongo es lo que tienes en checkpoint_timeout) asi que en cada
> checkpoint procesas solo 1 segmento de wal. yo le aumentaria un poco,
> quiza 30min al menos
>
> --
> Jaime Casanova www.2ndQuadrant.com
> Professional PostgreSQL: Soporte 24x7 y capacitación
>