Приветствую всех!

Помогите пожалуйста разобраться, при создании backup (база УПП) c помощью pg_dump выходит ошибка:

pg_dump: Ошибка выгрузки таблицы "config": сбой в PQgetResult().
pg_dump: Сообщение об ошибке с сервера: ОШИБКА:  invalid memory alloc request size 1413706665
pg_dump: Выполнялась команда: COPY public.config (filename, creation, modified, attributes, datasize, binarydata) TO stdout;

Эта тема уже здесь обсуждалась, КА 1.1.107.4 - проблемы с архивацией на СУБД Postgres что если размер строки больше 1гб, то выходит ошибка. Вариант решения бэкапить 3 командами вместо одной.
    
1. Создаем сам дамп, без проблемной таблицы.
2. Выгружаем схему проблемной таблицы.
3. Копируем таблицу в бинарном веде в файл.

$ pg_dump -Z 9 -T <таблица> -f <имя_дампа>.dump.gz <имя_базы>
где
<таблица> - config
<имя_дампа> - произвольное имя??? или откуда его взять
<имя_базы> - test

$ pg_dump -t <таблица> -s -f <имя_схемы>.shema <имя_базы>
где
<имя_схемы> - где его взять?

$ psql -d <имя_базы> -c "COPY public.<таблица> TO '/var/lib/postgresql/<имя_таблицы>.tabl' WITH BINARY;"
где
<таблица> - config
<имя_таблицы>.tabl - тоже config получается?

Где взять инфу имя_схемы, имя_дампа?

pg_dumpbinary/pg_restorebinary https://github.com/lzlabs/pg_dumpbinary давно и успешно решает эту задачу.
Имя дампа на усмотрение пользователя.

(0) Попробуй конфигурацию поставщика удалить

(2) Еси удалить то все заработает, но наши 1С-ники против

Ну вариантов не особо. Либо бэкапить кластер целиком через pg_basebackup (большие базы часто специально поднимают в отдельных кластерах, это удобно по нескольким причинам), либо юзать сторонние утилиты для бэкапа, либо юзать коммерческие сборки постгри в которых эта плюшка уже на борту обычно.

Бэкапить проблемную таблицу отдельно - это как-то совсем не по-людски.

(4)
>либо юзать коммерческие сборки постгри в которых эта плюшка уже на борту
в каких сборках это есть?

(0) О! Чего нагуглил. Попробуй опцию -F c для pg_dump.

Это по следам чьей-то заметки на гитхабе: https://gist.github.com/jdeoliveira/4080656

(6) Возможно наврал. Почему-то был уверен, что в postgres pro это есть. И где-то еще давно слышал, но не помню где. Эхо каких-то презентаций.

выгружай отдельно
pg_dump ... --exclude-table-data=config ...
psql -c "\copy config TO 'path/config.bin' WITH BINARY;"

загружай отдельно
psql -c "\copy config FROM 'path/config.bin' WITH BINARY;"

(7) Не помогает

(11) Эх. Да, это было бы слишком просто.

Подскажите пжл установил pg_dumpbinary, делаю пробный backup, но выходит ошибка типа в строке 179 нет пароля. как решить проблему?

postgres@1c-server-test:/opt/pg_dumpbinary-master$ pg_dumpbinary  -d doccorpеtest /opt/doccorptest2
Database doccorptest dump created at 2021-10-04T18:13:41
DBI connect('dbname=doccorptest;port=5432','',...) failed: fe_sendauth: no password supplied at /usr/local/bin/pg_dumpbinary line 179.

179 строка выглядит вот так

$dbh = DBI->connect("dbi:Pg:dbname=$DBNAME$dbpg_opt", $DBUSER, '', {AutoCommit => 1, InactiveDestroy => 1});

(0) если еще актуально

$ pg_dump -Z 9 -T <таблица> -f <полный путь к хранилищу архивов><имя_дампа>.dump.gz <имя_базы>
где
<таблица> - config
<имя_дампа> - произвольное имя, например имя базы
<имя_базы> - test

$ pg_dump -t <таблица> -s -f <полный путь к хранилищу архивов><имя_файла_схемы> <имя_базы>
где
<имя_файла_схемы> - любое, например "config.shema.dump"

$ psql -d <имя_базы> -c "COPY public.<таблица> TO '<полный путь к хранилищу архивов><имя_файла_таблицы>' WITH BINARY;"
где
<таблица> - config
<имя_файла_таблицы> - любое имя, например "public.config.dump"

Для сохраняемых файлов лучше указывать полный путь к хранилищу архивов.

ключик -Fc разве не помогает?

(15)+ для pg_dump

(15) В (11) пишут, что не помогает.

(17) ты сам проверял?
у нас все ок, хотя конечно возможно что нет таких табличек больших

(18) У меня нет такой проблемы. Да и постгри уже нет несколько лет :)
У тебя скорее всего тоже нет такой проблемы. Тут же не в размере таблички проблема. А в полуторагиговой строке.

Вообще подозрительно, что конфа столько весит. Такое бывает вследствие каких-то сбойных элементов конфы.
Я бы попробовал выгрузить конфу в файлы и натравить на нее TreeSize - глянуть, чего там в топах.

(19) у нас скорее всего версия PostgreSQL уже патченая 11 и эта трабла не возникает

(13) Задать пароль в файле .pgpass  https://postgrespro.ru/docs/postgresql/13/libpq-pgpass

(3) а почему они против? может найдем способ по-нормальному это сделать

(13) Побороли проблему

(24) с DBI connect('dbname=doccorptest;port=5432','',...) failed: fe_sendauth: no password supplied at /usr/local/bin/pg_dumpbinary line 179.

изменил
local all postgres trust

Вроде процесс пошел, НО

Пытаюсь создать бэкап от имени пользователя postgres в папку  /opt/backuptest дал пользователю postgres права на запись в эту папку. Выходит ошибка не дает сделать dump в любую папку кроме как с /var/lib/postgresql/10/main.

pg_dumpbinary  -d doccorplena /opt/backuptest/doccorptest2
Database doccorplena dump created at 2021-10-05T13:40:03
FATAL: can not save snapshot information to file .snapshot_info

Файла .snapshot_info не могу найти в системе, какая-то фигня

(26) postgres@1c-server-test:/opt$ ls -alF /opt/backuptest
итого 16
drwxrwxr-x  4 postgres postgres 4096 окт  5 13:40 ./
drwxr-xr-x 10 root     root     4096 окт  5 12:28 ../
drwxrwxr-x  2 postgres postgres 4096 окт  5 12:33 doccorptest/
drwxrwxr-x  2 postgres postgres 4096 окт  5 13:40 doccorptest2/

(26) Создать папочку и chown на postgres:postgres сделать. Не?

разобрались надо прямо перейти в паку куда будет делаться backup у меня это /opt/backuptest и там уже команду запускать, мануала четкого нет, поэтому пальцем в небо

postgres@1c-server-test:/opt/backuptest$ pg_dumpbinary  -d doccorplena doccorptest1

Бэкап сделался вроде все норм, сейчас будем пробовать восстановить, после отпишусь

Не получается восстановить базу.

postgres@1c-server-test:/opt/backuptest$ pg_restorebinary -d doccorplena doccorpbackup
Restoring pre data section into upptest1.
ERROR: pg_restore error to obtain dump information for table structure.

Может кто-нибудь пользуется pg_dumpbinary/pg_restorebinary помогите решить проблему

в мануале вот что написано:

pg_restorebinary

Program used to restore a PostgreSQL binary dump generated with pg_dumpbinary. It can not be used to restore other PostgreSQL dump.

usage: pg_restorebinary [options] -d dbname backup_dir

  backup_dir   directory where backup files to restore will be read.
               It must be a directory created by pg_dumpbinary.
options:

  -a, --data-only              restore only the data, no schema
  -d, --database DBNAME        database to restore, it must exists
  -h, --host HOSTNAME          database server host or socket directory
  -i, --info                   print information about the dump and exit
  -j, --job NUM                use this many parallel jobs to restore
  -n, --schema SCHEMA          restore the named schema(s) only
  -N, --exclude-schema SCHEMA  do NOT restore the named schema(s)
  -p, --port PORT              database server port number, default: 5432
  -t, --table TABLE            restore named relation
  -T, --exclude-table TABLE    do NOT restore the named table
  -u, --user NAME              connect as specified database user
  -v, --version                show program version
  --help                       show usage
  --disable-triggers           disable triggers during data restore
  --truncate                   truncate the table before importing the data

(23) Может не знают как обновлять базу после этого?
:)

(18) Я проверял. При архивации УПП 1.3 и КА 1.2 с измененной конфигурацией есть проблема из топика. У остальных конф нет.

Любая конфа размером больше 512 МБ в режиме редактирования с сохранением поддержки, например последняя типовая БГУ 2(573 МБ).

(31) А нельзя ли
- выгрузить конфигурацию
- конфигурацию поставщика удалить
- снять дампы
- вернуть конфигурацию как было до дампов
?

(34) Программист 1С не дает удалять конфу от поставщика, может я конечно что-о не догоняю. Хотелось бы все-таки разобраться с pg_dumpbinary. Неужели никто не бэкапит с помощью pg_dumpbinary?

(35) Укажи полный путь к backup_dir - /opt/backuptest/doccorptest2(или любой другой нужный) в твоем случае.

(35) первым будешь...
Что тебе мешает делать как все?

(36) не помогло, указал полный путь

postgres@1c-server-test:/opt/backuptest$ pg_restorebinary -d upptest1 /opt/backuptest/upptestbackup
Restoring pre data section into upptest1.
ERROR: pg_restore error to obtain dump information for table structure.

(38) а в новую чистую базу?

postgres:~> createdb testbkp
postgres:~> pg_restorebinary -j 2 -d testbkp /home/postgres/pgbackups/zkcopy1
Restoring pre data section into testbkp.
Restoring post data section.
Все восстанавливается, база работает.
(38) Посмотри какие файлы есть в каталоге upptestbackup? Должны быть data-public*.bin.gz, meta-public*.txt, data-sequences.lst, pre-data.dmp и post-data.dmp
Пользователь postgres должен иметь права на их чтение, хотя бы.

postgres:pgbackups> pg_restorebinary -info ~/pgbackups/zkcopy1
; Archive created at 2021-10-04 20:06:46 MSK
;     dbname: zkcopy1
;     Dumped from database version: 13.3
;     Number of tables to retore: 2052

(40) (41)
Все data-public*.bin.gz, meta-public*.txt, data-sequences.lst, pre-data.dmp и post-data.dmp файлы есть, даже выгрузка весит норм, но блин все равно не хочет загружаться и все.

postgres@1c-server-test:/opt/backuptest$ pg_restorebinary -j 2 -d upptest1 /opt/backuptest/upptestbackup
Restoring pre data section into upptest1.
ERROR: pg_restore error to obtain dump information for table structure.
postgres@1c-server-test:/opt/backuptest$ pg_restorebinary -info upptestbackup
; Archive created at 2021-10-05 13:52:58 +05
;     dbname: upptest1
;     Dumped from database version: 10.5 (Ubuntu 10.5-24.1C)
;     Number of tables to retore: 1824


а бэкап Вы так делаете ?

postgres@1c-server-test:/opt/backuptest$ pg_dumpbinary  -d upptest1 upptestbackup

postgres:~> pg_dumpbinary -d testbkp -j 2 /opt/backuptest/testbkp
Database testbkp dump created at 2021-10-11T18:17:46
Dumping pre data section at 2021-10-11T18:17:46
Dumping data at 2021-10-11T18:18:52
Dumping post data section at 2021-10-11T18:19:53
Dump ended at 2021-10-11T18:20:08
postgres:~> createdb testbkp11
postgres:~> pg_restorebinary -d testbkp11 -j 2 /opt/backuptest/testbkp
Restoring pre data section into testbkp11.
Restoring post data section.
PostgreSQL_13.3-2.1C, CentOS 7

Посмотрел содержимое таблицы config конфигурации в режиме редактирования с сохранением поддержки, размер конфигурации 573 МБ.
Похоже, конфигурация поставщика уже не хранится в одном поле binarydata. Вместо этого есть несколько десятков записей с размером бинарной строки поля binarydata 10МБ, а в поле datasize указан размер конфигурации в байтах.
Стандартный pg_dump выгружает без ошибок. Видимо, было изменение способа хранения конфигурации поставщика, начиная с какой-то версии платформы. Смотрел на 8.3.14 и 8.3.20
Так что, для этого случая, pg_dumpbinary и не нужен уже.

Эээээ а разве такие темы не 1-2 раза в квартал такие темы всплывают?

(45) Про мышей и кактусы - помнишь?

(46) а какатусы то при чем, если у мышей руки не оттудова?

(44) У меня стоит платформа 8.3.15.1656

при бэкапе pg_dump выдет ошибку ( не работает короче)

pg_dump: Ошибка выгрузки таблицы "config": сбой в PQgetResult().
pg_dump: Сообщение об ошибке с сервера: ОШИБКА:  invalid memory alloc request size 1413706665
pg_dump: Выполнялась команда: COPY public.config (filename, creation, modified, attributes, datasize, binarydata) TO stdout;

(43) попробую еще раз сегодня бэкап через pg_dumpbinary сделать

У   pg_dumpbinary как раз на github написано

pg_dumpbinary is useful in some situations:

you have bytea that can not be exported by pg_dump because the total size of the escape/hex output exceed 1Gb.

(47) Так мыши же.