Смоленск 1.5 Ошибка при инкрементальном резервном копировании

Сообщения
5
#1
Я проверял, как работает инкрементальное резервное копирование (архивирование журналов транзакций) в PostgreSQL из поставки Astra Linux SE (версия 9.4.5). Это называется Continuous Archiving and Point-in-Time Recovery (PITR) в документации Postgres'a.
Я создал каталог для сохранения этих журналов, дал на него права пользователю postgres, вписал в postgresql..conf необходимые команды архивации:
Код:
archive_mode = on
wal_level = archive
archive_command = 'test ! -f /BACKUP/backupfiles/wals`date +/%Y/%m/%d`/%f && mkdir -p /BACKUP/backupfiles/wals`date +/%Y/%m/%d/` && cp %p /BACKUP/backupfiles/wals`date +/%Y/%m/%d`/%f '
max_wal_senders = 5
и перезапустил БД,
Перед выполнением архивирования необходимо выполнить функцию БД pg_switch_xlog().
Код:
CREATE OR REPLACE FUNCTION switch_xlog()
  RETURNS text AS
'pg_switch_xlog'
  LANGUAGE internal VOLATILE STRICT SECURITY DEFINER
  COST 1;
ALTER FUNCTION switch_xlog()
  OWNER TO postgres;
GRANT EXECUTE ON FUNCTION switch_xlog() TO backup_replication;
На одном из серверов она выполняется, а на другом - СУБД отваливается и долго перезапускается (около 10 минут даже с небольшой тестовой БД). При этом в лог летит сообщение о падении процесса СУБД:
Код:
2018-12-19 19:28:17 MSK [16326-4] ОТМЕТКА:  процесс сервера (PID 17266) был завершён по сигналу 11: Segmentation fault
2018-12-19 19:28:17 MSK [16326-5] ПОДРОБНОСТИ:  Завершившийся процесс выполнял действие: select switch_xlog();
2018-12-19 19:28:17 MSK [16326-6] ОТМЕТКА:  завершение всех остальных активных серверных процессов
2018-12-19 19:28:17 MSK [16991-1] postgres@dbmain ПРЕДУПРЕЖДЕНИЕ:  закрытие подключения из-за краха другого серверного процесса
2018-12-19 19:28:17 MSK [16991-2] postgres@dbmain ПОДРОБНОСТИ:  Управляющий процесс отдал команду этому серверному процессу откатить текущую транзакцию и завершиться, так как другой серверный процесс завершился аварийно и возможно разрушил разделяемую память.
2018-12-19 19:28:17 MSK [16991-3] postgres@dbmain ПОДСКАЗКА:  Вы сможете переподключиться к базе данных и повторить вашу команду сию минуту.
2018-12-19 19:28:22 MSK [16326-7] ОТМЕТКА:  процесс архивации (PID 16602) был завершён по сигналу 9: Killed
2018-12-19 19:28:22 MSK [16326-8] ОТМЕТКА:  все серверные процессы завершены... переинициализация
2018-12-19 19:28:22 MSK [18025-1] ОТМЕТКА:  работа системы БД была прервана; последний момент работы: 2018-12-19 19:11:36 MSK
2018-12-19 19:35:03 MSK [18025-2] ОТМЕТКА:  система БД была остановлена нештатно; производится автоматическое восстановление
2018-12-19 19:35:03 MSK [18025-3] ОТМЕТКА:  запись REDO начинается со смещения 1/85000090
2018-12-19 19:35:03 MSK [18025-4] ОТМЕТКА:  неожиданный pageaddr 1/7D000000 в сегменте журнала 000000010000000100000086, смещение 0
2018-12-19 19:35:03 MSK [18025-5] ОТМЕТКА:  записи REDO обработаны до смещения 1/85000090
2018-12-19 19:35:03 MSK [18025-6] ОТМЕТКА:  Защита от наложения мультитранзакций сейчас включена
2018-12-19 19:35:03 MSK [16326-9] ОТМЕТКА:  система БД готова принимать подключения
2018-12-19 19:35:03 MSK [18234-1] ОТМЕТКА:  процесс запуска автоочистки создан
2018-12-19 19:36:32 [16326] АУДИТ: УСПЕХ, Подключение, 192.168.99.196, "dbmain", SU = "backup_replication" (16390), CU = "backup_replication" (16390): мандатная метка: {0,0} ignore_socket_maclabel
При этом со временем файлы с журналами накапливаются в указанном в команде archive_command каталоге. Но сброс файла вручную перед резервным копированием, для сохранения последнего состояния базы, не проходит.

Это какая-то ошибка в конфигурации или внутренняя ошибка СУБД? Что можно попробовать изменить или проверить?
 
Сообщения
5
#2
Stacktrace:

Код:
Program received signal SIGSEGV, Segmentation fault.
0x000055a9ff374510 in pg_detoast_datum_packed ()
(gdb) bt
#0  0x000055a9ff374510 in pg_detoast_datum_packed ()
#1  0x000055a9ff349a70 in text_to_cstring ()
#2  0x000055a9ff371e34 in FunctionCall1Coll ()
#3  0x000055a9ff37347e in OutputFunctionCall ()
#4  0x000055a9ff044679 in ?? ()
#5  0x000055a9ff186478 in standard_ExecutorRun ()
#6  0x000055a9ff28484f in ?? ()
#7  0x000055a9ff285cf7 in PortalRun ()
#8  0x000055a9ff282d4a in PostgresMain ()
#9  0x000055a9ff040294 in ?? ()
#10 0x000055a9ff22cad0 in PostmasterMain ()
#11 0x000055a9ff041112 in main ()
Видно, что падает на этапе разбора параметров, как будто параметры функции заданы неправильно, а не на этапе работы с файлом журнала.
 
Сообщения
5
#3
А, похоже, разобрался! Параметры были заданы неправильно (точнее, тип возвращаемого значения)!
В версии 9.3 (под которую скрипт БД писался раньше) функция возвращала text, а в новой версии - новый тип для представления позиции pg_lsn, который представлен в виде числа, а не строки. Поменял тип - стало нормально.