Я пытаюсь это использовать,
но пока по этому поводу ничего добавить не могу...
У меня другая проблема, по истечении checkpoint_timeout
не создается новый WAL файл и как следствие не архивируется на другой компьютер.
Может я что-то не так делаю ?
Может нужно использовать archive_timeout ?

Спасибо, понятно, сделал archive_timeout=120

Теперь пишутся WAL'ы почему-то через каждые 4 и 6 минут
по идее должны писаться через 2 минуты.

Теперь что мне не нравится....
Пишутся 16 MB каждые 2 минуты, даже если в базе вообще ничего не происходит.
За день должно набежать около 12000 MB !!!!

Как сделать, что-бы писалось только тогда, когда произошли изменения в базе ?
Если ничего не изменилось в базе, зачем писать WAL ?

Вероятно использование archive_timeout не рационально.
Надо попробовать pg_switch_xlog() как то "прикрутить"...

Я сейчас пробую на версии 8.2.6 - все работает.

pg_switch_xlog() поставил в cron с интервалом 1 минута.
Это позволяет на неактивной базе не создавать "пустых" WAL'ов,
как это происходит, если указать archive_timeout равное 1 минуте.

Увеличил checkpoint_timeout до 10 минут.
При этом регулярно через 10 минут получаю новый WAL файл
и если между checkpoint'ами происходит изменение базы,
то pg_switch_xlog() тоже создает новый WAL файл.

Явное указание archive_timeout=0 или нет - не играет роли,
если не указано, то оно равно 0.

Теперь вопросы:
1. На что влияет значение checkpoint_timeout ?
2. Что происходит при checkpoint'е ?
3. Если я укажу checkpoint_timeout равным 60 минут, какие могут быть неприятности ?

Испавления...

pg_switch_xlog() поставил в cron с интервалом 1 минута.
Это позволяет на неактивной базе не создавать "пустых" WAL'ов,
как это происходит, если указать archive_timeout равное 1 минуте.

А также pg_switch_xlog() создает новый WAL после checkpoint'а

Ответы на эти вопросы я еще не получил...
1. На что влияет значение checkpoint_timeout ?
2. Что происходит при checkpoint'е ?
3. Если я укажу checkpoint_timeout равным 60 минут, какие могут быть неприятности ?

Где лежит документация, я знаю.
Меня интересует практика использования этих параметов.

Т.е. если я поставлю checkpoint_timeout равным 3 часам,
то Postgresql будет как минимум хранить все WAL за последнии 3 часа ?

Если произойдет отказ оборудования, то рестарт базы
начнется от последнего checkpoint'а (который был создан около 3 часов назад) и
будет "проигрывать" все WAL'ы который создались после checkpoint'а ?

А на стороне "горячего" сервера при старте базы в режиме восстановления всеравно
будут использоваться ВСЕ WAL'ы начиная от последнего "полного" backup'а
не зависимо от checkpoint'ов ?

Вот представляю на "суд" общественности мои скрипты,
которые работают на сервере (CopyWAL.sh, SwitchWAL.sh, BackupDB.sh:)
и скрипт (RestoreDB.sh) который "запускает" базу на "горячем" backup сервере (k1):

CopyWAL.sh:
#!/bin/sh
/usr/bin/scp -p $1 postgres@k1:/var/lib/postgresql/WAL/$2

SwitchWAL.sh:
#!/bin/sh
/usr/bin/psql -h localhost -U postgres -c "select pg_switch_xlog()"

BackupDB.sh:
#!/bin/sh
/usr/bin/ssh postgres@k1 rm -rf /var/lib/postgresql/WAL.BAK
/usr/bin/ssh postgres@k1 mv /var/lib/postgresql/WAL /var/lib/postgresql/WAL.BAK
/usr/bin/ssh postgres@k1 mkdir -p /var/lib/postgresql/WAL
/usr/bin/ssh postgres@k1 chown postgres:postgres /var/lib/postgresql/WAL
/usr/bin/ssh postgres@k1 chmod 700 /var/lib/postgresql/WAL
/usr/bin/ssh postgres@k1 rm -rf /var/lib/postgresql/DB.BAK
/usr/bin/ssh postgres@k1 mv /var/lib/postgresql/DB /var/lib/postgresql/DB.BAK
/usr/bin/ssh postgres@k1 mkdir -p /var/lib/postgresql/DB
/usr/bin/ssh postgres@k1 chown postgres:postgres /var/lib/postgresql/DB
/usr/bin/ssh postgres@k1 chmod 700 /var/lib/postgresql/DB
DATE=`date +%Y%m%d_%H%M%S`
/usr/bin/psql -h localhost -U postgres -c "select pg_start_backup('Backup_$DATE')"
sleep 5
rm -rf /tmp/S.tar.gz
tar -czf /tmp/S.tar.gz /var/lib/postgresql/8.3/main
/usr/bin/scp -p /tmp/S.tar.gz postgres@k1:/var/lib/postgresql/DB/
rm -rf /tmp/S.tar.gz
sleep 5
/usr/bin/psql -h localhost -U postgres -c "select pg_stop_backup()"

RestoreDB.sh:
#!/bin/sh
/etc/init.d/postgresql-8.3 stop
sleep 5
rm -rf /var/lib/postgresql/8.3/main.BAK
mv /var/lib/postgresql/8.3/main /var/lib/postgresql/8.3/main.BAK
tar -xzf /var/lib/postgresql/DB/S.tar.gz -C /
rm -rf /var/lib/postgresql/8.3/main/pg_xlog/*
cp /var/lib/postgresql/recovery.conf /var/lib/postgresql/8.3/main/
/etc/init.d/postgresql-8.3 start

recovery.conf:
restore_command = 'cp /var/lib/postgresql/WAL/%f %p'

надеюсь, что кому-нибудь это поможет.

Забыл... вот еще ...

Изменения на сервере в postgresql.conf:
--- postgresql.conf.ORIGINAL 2008-02-05 00:29:15.000000000 +0100
+++ postgresql.conf 2008-02-05 14:51:36.000000000 +0100
@@ -54,6 +54,7 @@
# - Connection Settings -

#listen_addresses = 'localhost' # what IP address(es) to listen on;
+listen_addresses = '*' # what IP address(es) to listen on;
# comma-separated list of addresses;
# defaults to 'localhost', '*' = all
# (change requires restart)
@@ -170,14 +171,19 @@

#checkpoint_segments = 3 # in logfile segments, min 1, 16MB each
#checkpoint_timeout = 5min # range 30s-1h
+checkpoint_timeout = 10min # range 30s-1h
+
#checkpoint_completion_target = 0.5 # checkpoint target duration, 0.0 - 1.0
#checkpoint_warning = 30s # 0 is off

# - Archiving -

#archive_mode = off # allows archiving to be done
+archive_mode = on # allows archiving to be done
# (change requires restart)
#archive_command = '' # command to use to archive a logfile segment
+archive_command = '/usr/local/bin/CopyWAL.sh %p %f' # command to use to archive a logfile segment
+
#archive_timeout = 0 # force a logfile segment switch after this
# time; 0 is off

Это тоже на сервере WAL.cron:
0 */1 * * * /usr/local/bin/BackupDB.sh
* * * * * /usr/local/bin/SwitchWAL.sh

Сделал новый сервер...
Пытаюсь на нем восстановить Базу по вышеизложеной схеме (PITR):

#!/bin/sh
/etc/init.d/postgresql-8.3 stop
sleep 5
rm -rf /var/lib/postgresql/8.3/main.BAK
mv /var/lib/postgresql/8.3/main /var/lib/postgresql/8.3/main.BAK
tar -xzf /var/lib/postgresql/DB/S.tar.gz -C /
rm -rf /var/lib/postgresql/8.3/main/pg_xlog/*
cp /var/lib/postgresql/recovery.conf /var/lib/postgresql/8.3/main/
/etc/init.d/postgresql-8.3 start

... и вылетает сообщение:

Starting PostgreSQL 8.3 database server: main
Error: The server must be started under the locale : which does not exist any more.
failed!

Где может быть "собака зарыта" ?

На сервере где работает база:
root@s1:~# locale
LANG=de_DE.UTF-8
LC_CTYPE="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_PAPER="de_DE.UTF-8"
LC_NAME="de_DE.UTF-8"
LC_ADDRESS="de_DE.UTF-8"
LC_TELEPHONE="de_DE.UTF-8"
LC_MEASUREMENT="de_DE.UTF-8"
LC_IDENTIFICATION="de_DE.UTF-8"
LC_ALL=
root@s1:~#

На сервере, куда восстанавливается база:
k4:~# locale
LANG=de_DE.UTF-8
LC_CTYPE="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_PAPER="de_DE.UTF-8"
LC_NAME="de_DE.UTF-8"
LC_ADDRESS="de_DE.UTF-8"
LC_TELEPHONE="de_DE.UTF-8"
LC_MEASUREMENT="de_DE.UTF-8"
LC_IDENTIFICATION="de_DE.UTF-8"
LC_ALL=
k4:~#

Сервер, где база работает:
root@s1:/usr/lib/postgresql/8.3/bin# ./pg_controldata /var/lib/postgresql/8.3/main | grep LC_
LC_COLLATE: de_DE.UTF-8
LC_CTYPE: de_DE.UTF-8
root@s1:/usr/lib/postgresql/8.3/bin#

Сервер, где не идет восстановление:
k4:/usr/lib/postgresql/8.3/bin# ./pg_controldata /var/lib/postgresql/8.3/main | grep LC_
LC_COLLATE: de_DE.UTF-8
LC_CTYPE: de_DE.UTF-8
k4:/usr/lib/postgresql/8.3/bin#

Ошибся....
Дложно быть так:

Сервер, где база работает:
root@s1:/usr/lib/postgresql/8.3/bin# ./pg_controldata /var/lib/postgresql/8.3/main | grep LC_
LC_COLLATE: de_DE.UTF-8
LC_CTYPE: de_DE.UTF-8
root@s1:/usr/lib/postgresql/8.3/bin#

Сервер, где не идет восстановление:
k4:/usr/lib/postgresql/8.3/bin# ./pg_controldata /var/lib/postgresql/8.3/main | grep LC_
LC_COLLATE:
LC_CTYPE:
k4:/usr/lib/postgresql/8.3/bin#

И куда подевались LC_COLLATE и LC_CTYPE ?

postgres@k4:/usr/lib/postgresql/8.3/bin$ ./pg_controldata /var/lib/postgresql/8.3/main
WARNUNG: Berechnete CRC-Checksumme stimmt nicht mit dem Wert in der Datei
überein. Entweder ist die Datei kaputt oder sie hat ein anderes Layout
als von diesem Program erwartet. Die Ergebnisse unten sind nicht
verlässlich.

pg_control-Versionsnummer: 833
Katalogversionsnummer: 200711281
Datenbanksystemidentifikation: 5163271145988284406
Datenbank-Cluster-Status: im Produktionsmodus
pg_control zuletzt geändert: Do 01 Jan 1970 01:00:00 CET
Position des letzten Checkpoints: 47C2F42C/0
Position des vorletzten Checkpoints: A/D7000020
REDO-Position des letzten Checkpoints: A/D6000020
TimeLineID des letzten Checkpoints: 10
NextXID des letzten Checkpoints: 3607101472/1
NextOID des letzten Checkpoints: 0
NextMultiXactId des letzten Checkpoints: 969
NextMultiOffset des letzten Checkpoints: 24576
Zeit des letzten Checkpoints: Do 01 Jan 1970 01:00:01 CET
Minimaler Wiederherstellungsendpunkt: 0/47C2F42B
Maximale Datenausrichtung (Alignment): 0
Datenbankblockgröße: 8
Blöcke pro Segment: 0
WAL-Blockgröße: 0
Bytes pro WAL-Segment: 1093850759
Maximale Bezeichnerlänge: 8192
Maximale Spalten in einem Index: 131072
Maximale Größe eines Stücks TOAST: 8192
Speicherung von Datum/Zeit-Typen: 64-Bit-Ganzzahlen
Maximallänge eines Locale-Namens: 64
LC_COLLATE:
LC_CTYPE:
postgres@k4:/usr/lib/postgresql/8.3/bin$

Хотя WARNUNG есть WARNUNG, но всетаки тоже настораживает...