Добрый день.

На диске 1с предприятие сервер мини есть папка PostgreSQL, в которой есть два файла
postgresql-9.3.4-1.1C.msi
postgresql-9.3.4-1.1C-int.msi

Подскажите пожалуйста, чем они отличаются и какой надо запускать?
На сайте 1С есть версия 10.5-6.1C, стоит ли ставить последнюю версию?

(101) Корп то причем? Там только если больше 12 ядер и 500 пользователей реально что-то интересное. До 200 не нужно если руки прямые.

>>postgresql-9.3.4-1.1C.msi

Это совсем старье. Используй от postgresql.pro сборки - они даже сертифицированы. До 9.6 там совсем все печально с производительностью.

>>Вместо того, чтобы хранить метаданные как положено, в связанных таблицах, они тупо кладут всю конфигурацию в блоб.

8.3.15 ставь - там поправили. С 8.3.14 уже шло в одной таблице, но не одним блобом.

(109) можно! ДТ - уже архив, пройдись поверх дампа tar|gz.

(111)как обещал в (106)  8.3.14.1630 + 10.9.5-1С проверю в выхи... cf от upp1.3 уже достал.

(111) уже поставил:
- PostgreSQL Database Server 10.9-5.1C(x64) - это крайняя версия на сайте 1С
- 1С:Предприятие 8.3 (8.3.15.1656) - предпоследняя

+ сделал настройки кластера и сервера сделал..

вроде как "полет" нормальный..

(112) сделал бэкап так, затем создал в консоли пустую базу и через pgAdmin пробовал восстановить - не получилось.. ошибки..

(115) создавай базу через pg admin , восстанавливай в нее и потом уже подключай ее к серверу 1С

CREATE DATABASE test
  WITH OWNER = postgres
       ENCODING = 'UTF8'
       TABLESPACE = pg_default
       LC_COLLATE = 'ru_RU.UTF-8'
       LC_CTYPE = 'ru_RU.UTF-8'
       CONNECTION LIMIT = -1;

(0) месяц как заменил Postgres Pro 9.6 на сборку от 1С 10.9-5.1C(x64)

пользователи не разницы не заметили, перепроведение стало чуть чуть шустрее

Здравствуйте.Хочу попробовать перейти на 10.9-5.1C(x64). Чем можно и лучше заменить логшипинг MSSQL?

(116) Не получилось.. Пробовал и в консоли 1С делать базу, и в pgAmin, и через платформу 1С..

Бэкап делается с помощью pgAmin или скрипта, а вот восстановление в чистую базу не получается.

Может кто то поделиться скриптами? :)

(119) https://postgrespro.ru/docs/postgrespro/10/app-pgrestore

(118) А зачем? в слоне  Wal а не логшиппинг - это версионник, а не блокировщик.

(121) Мне главное аналогичный конечный результат. WAL значит, спасибо

(120) а можно выводить сам процесс восстановления в файл?

пишу
--file=C:\restore.log

оишбка
ещ ьфтн сщььфтв ...

(120) у меня на "черном" экране в консоли вывелось :)

warning: errors ignored on restore: 3


а вот что это за ошиьки не совсем понятно..

А еще смущает следующее сообщение при бэкапе

pg_dump: dumping contents of table "public.config"
pg_dump: Dumping the contents of table "config" failed: PQgetResult() failed.
pg_dump: Error message from server: ERROR:  out of shared memory
HINT:  You might need to increase max_locks_per_transaction.
pg_dump: The command was: COPY public.config (filename, creation, modified, attributes, datasize, binarydata, partno) TO stdout;



так запустишь ночью, а потом ничего не восстановится..

Ставь ванильный Постгрес, сдались тебе эти патчи

(125) В ссылке из (80) и в (99) подробно описано, почему выдаются такие сообщения.
В (107) - краткое описание того, как можно обойти проблему.
Здесь - http://catalog.mista.ru/public/956734/ готовое решение в виде команд для скриптов с подробным описанием их работы.

(126) патчи - я понимаю, что это все от 1C :)

ванильный Постгрес - ??

(127) "Ниже привожу примеры bat-файлов (качайте) " - не качается :)

(128) https://ru.wikipedia.org/wiki/Ванильное_ядро

В юникс-мире ПО ванильный = оригинальный, типа ствол дерева от которого уже ответствления всякие делаются

(129) Замени catalog.mista на infostart  и все скачается.

(132) просит стартмани.. у меня нет..

можете прислать на [email protected] ??

(126) Строки полетят и поиск. Патчи как раз сравнение исправляют.

(126) "иди проспись" ((С) Cyberhawk)

(133)

pg_dump --host=localhost4 --username=postgres --no-password --format=c --file=buh.backup buh
pg_restore --host=localhost4 --clean --if-exists --jobs=2 --username=postgres --dbname=buh buh.backup

https://postgrespro.ru/docs/postgresql/10/app-pgdump

пароль можно в файлик .pgpass записать и кинуть в домашний каталог пользователя от имени которого выполняются скрипты. Формат файла тоже в справке есть

Кстати базу (когда все на одном компе) можно подключать без TCP/IP, а по Unix сокетам,
путь к серверу в свойствах базы надо прописать /tmp
в основном конф файле есть параметр где оно сокеты создает

я восстанавливал так
сначала создаем пустую базу в pg_admin, не подключаем ее к 1С, потом pg_restore, потом подрубаем базу в сервере 1С предприятия 1С.

(138) не получается..

думаю тут все правильно сказали - (127)

нужны такие скрипты, так как выгрузка идет через раз..

(125) а параметр max_locks_per_transaction в конфиге сколько стоит?

(140) по моему я его не менял, вот
max_locks_per_transaction = 150    # min 10


кстати, получилось сделать бэкап/ресторе без ошибок через pgAdmin как написано тут
http://catalog.mista.ru/public/540298/

как советовали тут (139)

(141) так я про это еще в (116) писал

> создавай базу через pg admin , восстанавливай в нее и потом уже подключай ее к серверу 1С

CREATE DATABASE

(142) пропустил наверное, спасибо :)

(99) забавно...
1.создал пустую базу.
2.из конфигуратора объединил с cf
3.выгрузил pg_dump.exe -c  -C -v -f C:\test\upp_.sql
4.грохнул базу
5.загружал так:
   SET PGBIN=C:\Program Files (x86)\PostgreSQL\10.9-5.1C\bin\
   SET PGDATABASE=upp_test
   SET PGHOST=127.0.0.1
   SET PGPORT=5432
   SET PGUSER=postgres
   SET PGPASSWORD=**********
   createdb
   PAUSE
   psql -f C:\DSK\upp_.sql

Итого получаем базу, в консоли кластера она подключается, но в конфигураторе ИБ как буд-то созданная для разработки... сам каталог СУБД с базой 200 с небольшим мег.
Проверяю гипотезу с таблицей config:
select count(*) from configsave
-----------
0

н-да, придётся скрипт бэкапа допиливать.

делал бэкап так:

+ (144) каталоги для загрузки и выгрузки разные - это норм, из одного в другой ручками переносил

Добрый день.

Если у меня есть выгрузка кластера db.out, то как сделать его восстановление?

Командой pg_restore -d имя_БД имя_файла?

А надо же указать наверное сервер, порт. Подсмкажите пожалуйста

pg_restore.exe -h=localhost -p=5432 -U=postgres -d=zup2014 -f=c:\1.log  c:\db.out --verbose

??

Делаю вот так
pg_restore.exe --host localhost --port 5432 --username postgres --dbname z2014 --clean --verbose C:\db.out


выдается
pg_restore: [archiver] input file does not appear to be a valid archive


Скажите пож, можно ли узнать по структуре как делался бэкап и как восстановить одну базу, если в файле db.out содержится


--
-- PostgreSQL database cluster dump
--

SET default_transaction_read_only = off;

SET client_encoding = 'UTF8';
SET standard_conforming_strings = on;

--
-- Roles
--

CREATE ROLE postgres;
ALTER ROLE postgres WITH SUPERUSER INHERIT CREATEROLE CREATEDB LOGIN REPLICATION BYPASSRLS PASSWORD 'md54ef7cf478a39b5af1a2d160388faf58f';






--
-- Database creation
--

CREATE DATABASE a2014 WITH TEMPLATE = template0 OWNER = postgres;
CREATE DATABASE a2019 WITH TEMPLATE = template0 OWNER = postgres;
CREATE DATABASE centr WITH TEMPLATE = template0 OWNER = postgres;
CREATE DATABASE retailpharmacy_demo WITH TEMPLATE = template0 OWNER = postgres;
REVOKE CONNECT,TEMPORARY ON DATABASE template1 FROM PUBLIC;
GRANT CONNECT ON DATABASE template1 TO PUBLIC;
CREATE DATABASE testgilev WITH TEMPLATE = template0 OWNER = postgres;
CREATE DATABASE z2014 WITH TEMPLATE = template0 OWNER = postgres;
CREATE DATABASE z2014_old WITH TEMPLATE = template0 OWNER = postgres;
CREATE DATABASE z2014_test WITH TEMPLATE = template0 OWNER = postgres;
CREATE DATABASE z2019 WITH TEMPLATE = template0 OWNER = postgres;

(148) У тебя просто скрипт, который надо скормить ПСКЛ-ю.
Точнее смотреть тут: https://www.postgresql.org/docs/11/backup-dump.html#BACKUP-DUMP-RESTORE

(149) то есть
1 надо сделать пустую базу в pgАдмине, например test
2 выполнить psql --set ON_ERROR_STOP=on dbname < dumpfile
где dbname = test, dumpfile = C:\db.out


а как подключаться к ккластеру?

Тут на русском документация:
https://postgrespro.ru/docs/postgrespro/11/backup-dump#BACKUP-DUMP-RESTORE

(151) это одно и тоже. не совсем понимаю, как выполнить подключение.

psql -h localhost z2014

так?

(151) а тут psql --set ON_ERROR_STOP=on имя_базы < файл_дампа

то есть

psql --host localhost --set ON_ERROR_STOP=on z2014 < C:\db.out

1 сделал пустую z2014
2 выполнил
psql --host localhost --port 5432 --username postgres --set ON_ERROR_STOP=on z2014 < C:\db.out

3 получил ошибку

role "postgres" already exists

Файл начинается

--
-- PostgreSQL database cluster dump
--

SET default_transaction_read_only = off;

SET client_encoding = 'UTF8';
SET standard_conforming_strings = on;

--
-- Roles

--

CREATE ROLE postgres;



Может это надо запускать при пустом кластере как то?

(155) Да, у тебя полный дамп всего кластера, вообще всех баз и прочего...
Восстановить все:
psql -f all_databases.sql
(отсюда) https://the-bosha.ru/2016/06/01/backup-restore-postgresql-bazy-dannykh-s-pg_dump/

Восстановить одну базу там просто так не получится. Например: https://stackoverflow.com/questions/31525731/is-it-possible-to-import-one-database-from-pg-dumpall
или: https://www.sql.ru/forum/370756/vosstanovlenie-odnoy-tablicy-iz-polnogo-backup-a-bazy

(156) у меня файл db.out. сервер виндовый.

в консоле пишу
psql -f db.out

так? а где прописано, что надо подключиться к серверу?

(157)
"Подключение к базе данных
psql это клиент для PostgreSQL. Для подключения к базе данных нужно знать имя базы данных, имя сервера, номер порта сервера и имя пользователя, под которым вы хотите подключиться. Эти свойства можно задать через аргументы командной строки, а именно -d, -h, -p и -U соответственно. Если в командной строке есть аргумент, который не относится к параметрам psql, то он используется в качестве имени базы данных (или имени пользователя, если база данных уже задана). Задавать все эти аргументы необязательно, у них есть разумные значения по умолчанию. Если опустить имя сервера, psql будет подключаться через Unix-сокет к локальному серверу, либо подключаться к localhost по TCP/IP в системах, не поддерживающих UNIX-сокеты. Номер порта по умолчанию определяется во время компиляции. Поскольку сервер базы данных использует то же значение по умолчанию, чаще всего указывать номер порта не нужно. Имя пользователя по умолчанию, как и имя базы данных по умолчанию, совпадает с именем пользователя в операционной системе."
Весьма хорошая документация на русском - https://postgrespro.ru/docs/postgresql/10/app-psql
Дальше тоже можно почитать, так, для разнообразия.

(158) как я показал, в файле db.out написано

CREATE ROLE postgres;
ALTER ROLE postgres WITH SUPERUSER INHERIT CREATEROLE CREATEDB LOGIN REPLICATION BYPASSRLS PASSWORD 'md54ef7cf478a39b5af1a2d160388faf58f';


--
-- Database creation
--

CREATE DATABASE a2014 WITH TEMPLATE = template0 OWNER = postgres;
CREATE DATABASE


а когда я ставлю сервер и указываю параметры кластера, то он создается и
в нем уже есть база postgre, роль postgres..


и если выполню psql -f db.out, то будет же ошибка про то, что роль есть.

Сам кластер надо удалить?

(159) Вы читали ссылку на sql.ru из (156)?

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

(159) делайте дампы не в SQL формате, а в формате Postgres, в pg_dump кажется есть ключик, и не придется мучаться с редактированием огромного SQL скрипта.

PostgreSQL 10.10-1.1C и 11.5-1.1C вышли сегодня, причем, сразу актуальной версией.

(162) забавно, обе что-б не ниже 8.3.14.1565.

После перегрузки сервера Служба постгри не запускается.

Как исправить?

(164) Смотри в журнале событий, он туда пишет почему не может запуститься. Если сервер на Винде.

+(165) иногда и в логфайле постгри бывает ценная инфа.

И да... на одном сервере под виндой была странная фигня: служба стартовала и через 1-2 мин стопалась, но постгри норм работал.

(165) на винде..
А ещё, при установке был пользователь постгри, работали с базой, а сейчас его нет.
Не нормально же.

В журнале написано про postmaster.pid

(167) С копии восстанавливались?

(168) архивы то есть, но зайти в базу не могу, сервер не запускается

Подскажите как запустить это сервер?
Уже готов вернуться в файловый вариант

Вообщем как результат, были танцы с бубном, но в базу зашли.
В итоге все работаем, служба не запущена, однако в процессах висит postgres.exe.

Тогда теоретический вопрос, почему служба PostgreSQL Database Server 10.9-5.1C(x64) падает и не запускается? Что с этим делать?

(167) >>В журнале написано про postmaster.pid
Что именно написано? Если "FATAL:  lock file "postmaster.pid" already exists",
то нужно остановить службу PostgreSQL(может быть даже просто прибить postgres.exe, если он не завершается сам), потом удалить его и снова запустить службу. Смотреть что пишет в каталог pg_log, в последний по времени файл лога.
Если что-нибудь о "recovery", значит, какие-то данные были повреждены, то лучше создать новый кластер и восстановить в него базы из заведомо годного бэкапа.
Как мог пользователь postgres просто пропасть...

(172) это журнал виндовс

< 2019-10-29 07:18:40.796 MSK >FATAL:  lock file "postmaster.pid" already exists
< 2019-10-29 07:18:40.796 MSK >HINT:  Is another postmaster (PID 4700) running in data directory "D:/PostgreData"?




а это весь лог постгри
< 2019-10-29 06:45:59.678 MSK >LOG:  received fast shutdown request
< 2019-10-29 06:45:59.678 MSK >ERROR:  canceling statement due to user request
< 2019-10-29 06:45:59.818 MSK >LOG:  aborting any active transactions
< 2019-10-29 06:45:59.834 MSK >LOG:  worker process: logical replication launcher (PID 5116) exited with exit code 1
< 2019-10-29 06:45:59.834 MSK >LOG:  shutting down
< 2019-10-29 06:46:00.598 MSK >LOG:  database system is shut down
< 2019-10-29 06:52:11.993 MSK >LOG:  database system was shut down at 2019-10-29 06:46:00 MSK
< 2019-10-29 06:52:12.227 MSK >LOG:  database system is ready to accept connections
< 2019-10-29 07:04:13.256 MSK >LOG:  could not open file "postmaster.pid": No such file or directory
< 2019-10-29 07:04:13.256 MSK >LOG:  performing immediate shutdown because data directory lock file is invalid
< 2019-10-29 07:04:13.256 MSK >LOG:  received immediate shutdown request
< 2019-10-29 07:04:13.256 MSK >LOG:  could not open file "postmaster.pid": No such file or directory
< 2019-10-29 07:04:13.285 MSK >WARNING:  terminating connection because of crash of another server process
< 2019-10-29 07:04:13.285 MSK >DETAIL:  The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
< 2019-10-29 07:04:13.285 MSK >HINT:  In a moment you should be able to reconnect to the database and repeat your command.
< 2019-10-29 07:04:13.291 MSK >WARNING:  terminating connection because of crash of another server process
< 2019-10-29 07:04:13.291 MSK >DETAIL:  The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
< 2019-10-29 07:04:13.291 MSK >HINT:  In a moment you should be able to reconnect to the database and repeat your command.
< 2019-10-29 07:04:13.499 MSK >LOG:  database system is shut down
< 2019-10-29 07:05:18.589 MSK >LOG:  database system was interrupted; last known up at 2019-10-29 06:57:13 MSK
< 2019-10-29 07:16:26.998 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:16:55.684 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:16:57.557 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:16:58.376 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:16:59.505 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:18:00.348 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:18:01.819 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:18:03.537 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:18:24.544 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:19:03.914 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:19:08.216 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:19:08.967 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:19:28.636 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:20:05.767 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:20:14.494 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:20:33.328 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:20:34.012 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:21:08.300 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:21:19.622 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:21:38.329 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:21:57.307 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:22:11.379 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:22:25.481 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:22:42.835 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:23:01.842 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:23:15.886 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:23:28.905 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:23:48.062 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:24:07.117 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:24:20.917 MSK >LOG:  could not open file "postmaster.pid": No such file or directory
< 2019-10-29 07:24:20.917 MSK >LOG:  performing immediate shutdown because data directory lock file is invalid
< 2019-10-29 07:24:20.917 MSK >LOG:  received immediate shutdown request
< 2019-10-29 07:24:20.917 MSK >LOG:  could not open file "postmaster.pid": No such file or directory
< 2019-10-29 07:24:20.958 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:24:20.977 MSK >LOG:  database system is shut down
< 2019-10-29 07:25:49.350 MSK >LOG:  database system was interrupted; last known up at 2019-10-29 06:57:13 MSK
< 2019-10-29 07:26:00.999 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:26:19.209 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:26:33.411 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:26:46.618 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:27:04.144 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:27:24.173 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:27:38.396 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:27:50.978 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:28:09.535 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:28:29.045 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:28:43.821 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:28:56.071 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:29:14.536 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:29:35.986 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:29:48.222 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:29:57.438 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:30:20.932 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:30:40.968 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:30:53.000 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:30:59.716 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:31:22.831 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:31:44.137 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:31:58.215 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:32:04.047 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:32:24.447 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:32:46.412 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:33:04.091 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:33:08.905 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:33:29.698 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:33:52.456 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:34:10.119 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:34:11.153 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:34:30.970 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:34:55.335 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:35:15.253 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:35:16.920 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:35:33.900 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:35:58.315 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:36:18.978 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:36:23.003 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:36:37.658 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:36:59.855 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:37:22.787 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:37:28.201 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:37:43.445 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:38:04.437 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:38:24.340 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:38:33.659 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:38:45.789 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:39:08.709 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:39:27.780 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:39:37.747 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:39:47.734 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:40:09.961 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:40:32.308 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:40:42.698 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:40:52.220 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:41:11.019 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:41:34.039 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:41:46.148 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:41:55.168 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:42:15.607 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:42:36.191 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:42:52.279 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:42:57.267 MSK >FATAL:  the database system is starting up
< 2019-10-29 07:43:03.673 MSK >LOG:  database system was not properly shut down; automatic recovery in progress
< 2019-10-29 07:43:04.009 MSK >LOG:  redo starts at 1/9D3973E8
< 2019-10-29 07:43:04.009 MSK >LOG:  invalid record length at 1/9D3974C8: wanted 24, got 0
< 2019-10-29 07:43:04.009 MSK >LOG:  redo done at 1/9D397490
< 2019-10-29 07:43:04.642 MSK >LOG:  database system is ready to accept connections




но при этом сейчас все в базе и работаем

(172) это
" Если "FATAL:  lock file "postmaster.pid" already exists",
то нужно остановить службу PostgreSQL(может быть даже просто прибить postgres.exe, если он не завершается сам), потом удалить его и снова запустить службу. "   -  поздно заметил.. попробую вечером, когда сделаю архив базы :)..


и все таки..
почему служба PostgreSQL Database Server 10.9-5.1C(x64) падает и не запускается?

(173) мб у вас что то с UAC? или ставили из под администратора, а запускаете под непривилегированным? или несколько инстансов
(помогите не могу попасть себе в коленку)

(175) UAC по умолчанию (третья снизу :) )
ставили из под администратора - да
запускаете под непривилегированным - нет, просто сервер перегрузил, служба не запускается
несколько инстансов - нет

(176) Если после перезагрузки пишет вот то, что выше. То это значит, что у вас этот ПИД остался, возможно принудительно завершили процесс и он не успел за собой почистить. Останавливаете/прибиваете процессы постгре. Удаляете этот файл вручную (по сути это просто флаг для других процессов, что одна копия уже запущена и другие стартовать не надо). После чего ребутаете сервер и смотрите - что там с этой службой.

(177) делал
1 Останавливаете/прибиваете процессы постгре
2 Удаляете этот файл вручную

Запускаю службу pgsql-10.9-5.1C-x64 - пишет, что запущена и остановлена ...

Смотрю в диспетчере, а там несколько процессов postgres.exe и при этом нормально заходим в 1С и работаем.

Можно конечно "махнуть рукой", рабоаает и хорошо, но очень хотелось бы разобраться как поступать все таки в таком случае, что бы указанная служба все таки работала.

Ка вариант сделать архивы, снести сервер, поставить снова, развернуть архивы.

Но потом снова что то случится и такая ситуация повториться.

Пробовал как тут, но не помогло
https://mironovs.com/databases/vosstanovlenie-postgresql-posle-povrezhdeniya-fajlov-xlog.html


Поделитесь пож своим опытом, как в таком случае сделать "красивую" работу сервера?

(178) я бы снес и поставил свежак от 1С.
как это pid есть, а службы нет, хрень какая-то.

(179) я бы снес и поставил свежак от 1С - так и сделаю, но на будущее хотелось бы понять, почему служба не работает, процессы висят и база функционирует нормально..

pid есть, а службы нет - согласен.. удаляю его, а он снова появляется..

(180) Ну смотри, раз появляется - значит его кто-то создает. Возможно Постгре какой-то. Но при этом, по какой-то причине, оный падает с ошибкой и файл после него остается.
Либо наоборот, у тебя все работает правильно, и этот файл создают те самые - рабочие процессы Постгре. (Они же у тебя висят в процессах?)
А может на компе несколько версий Постгре и файл создает другая копия.
А может... хотя не, пока моя фантазия закончилась...

(181) то есть на саму службу можно не обращать внимание?

(178) у нас такая фигня была с полгода (писал в (166)), т.е. заметили но работает-же и забыли... снесли и повторно переустановили - стабилизировалось

(183) да, я видел..
у меня тоже работает и нормально..

Писали, что вышли
11.5-1.1C     28.10.19         
10.10-1.1C     28.10.19


Никто не ставил еще? :)

(184) 11.5-1.1C тестировал.
pgbench показывает несколько больший результат, чем на 10-й версии, процентов на 12-15. Плюс появилось создание индексов в несколько потоков, так что восстановление из бэкапа, загрузка .dt файла и просто реиндексация будут быстрее. Надо только указать в настройках желаемое число потоков, если количество ядер позволяет, конечно.
Тест Гилева отличий не показал, а многопоточный тест(Fragsтеr-а)был немного быстрее , на 5-7 процентов. Наши рабочие, практически типовые, конфигурации ведут себя нормально, без эксцессов.
Так что, наверное, поставлю на днях.

(163) Видимо, поддерживать "зоопарк" платформ и тестировать на них посчитали достаточно накладным. Пока еще тестовая зарплата 3.1.12 уже требует не ниже 8.3.14, думаю, что за ней и остальные типовые, в скором времени, подтянутся.

(185) >Надо только указать в настройках желаемое число потоков
в conf?

(187) Да, max_parallel_maintenance_workers. По умолчанию стоит значение 2. На не очень маленьких  таблицах в несколько млн. записей и размером от 1.5-2 ГБ эффект ощутим. Пока работает только с индексами B-tree, но 1С, вроде, других и не делает.

(188) даже когда всякие гео-ориентированные индексы 1С будет делать (что-то про гео и 1С где-то встречал) - наиболее часто используемыми останутся "сбалансированные деревья", имхо.

а покажите плз оптимальный конфиг на 11

(190) нет оптимальной настройки под сферический сервер в вакууме выполняющий сферическую задачу. Есть к примеру неплохие таки рекомендации 1С по настройке сервера постгри, больше всего настройка зависит от памяти сервера.

Наваял, не знаю насколько оптимально. Покритикуйте плз, 45,87 гилевских попугаев,

# ОЗУ 64ГБ, 12 ядер, SSD NVME RAID1,  

max_connections = 500            # (change requires restart)
unix_socket_directories = '/var/run/postgresql'    # comma-separated list of directories
ssl = off
shared_buffers = 16GB            # min 128kB
temp_buffers = 256MB            # min 800kB#
work_mem = 1GB                # min 64kB
maintenance_work_mem = 2GB        # min 1MB
dynamic_shared_memory_type = posix    # the default is the first option
max_files_per_process = 8000        # min 25
bgwriter_delay = 20ms            # 10-10000ms between rounds
bgwriter_lru_maxpages = 400        # max buffers written/round, 0 disables
bgwriter_lru_multiplier = 4.0        # 0-10.0 multiplier on buffers scanned/round
effective_io_concurrency = 200        # 1-1000; 0 disables prefetching
fsync = on                # flush data to disk for crash safety
synchronous_commit = off        # synchronization level;
commit_delay = 1000            # range 0-100000, in microseconds
commit_siblings = 5            # range 1-1000
max_wal_size = 4GB
min_wal_size = 2GB
checkpoint_completion_target = 0.9    # checkpoint target duration, 0.0 - 1.0
random_page_cost = 1.1                # same scale as above
effective_cache_size = 48GB
from_collapse_limit = 20
join_collapse_limit = 20        # 1 disables collapsing of explicit
log_destination = 'stderr'        # Valid values are combinations of
logging_collector = on        # Enable capturing of stderr and csvlog
log_directory = 'pg_log'        # directory where log files are written,
log_filename = 'postgresql-%a.log'    # log file name pattern,
log_truncate_on_rotation = on        # If on, an existing log file with the
log_rotation_age = 1d            # Automatic rotation of logfiles will
log_rotation_size = 0        # Automatic rotation of logfiles will
log_line_prefix = '%m [%p] %q%u@%d '            # special values:
log_timezone = 'Europe/Moscow'
cluster_name = '11/main'            # added to process titles if nonempty
stats_temp_directory = '/var/run/postgresql/11-main.pg_stat_tmp'
autovacuum = on            # Enable autovacuum subprocess?  'on'
autovacuum_max_workers = 6        # max number of autovacuum subprocesses
autovacuum_naptime = 20s        # time between autovacuum runs
datestyle = 'iso, dmy'
timezone = 'Europe/Moscow'
lc_messages = 'ru_RU.UTF-8'            # locale for system error message
lc_monetary = 'ru_RU.UTF-8'            # locale for monetary formatting
lc_numeric = 'ru_RU.UTF-8'            # locale for number formatting
lc_time = 'ru_RU.UTF-8'                # locale for time formatting
default_text_search_config = 'pg_catalog.russian'
shared_preload_libraries = 'online_analyze, plantuner'    # (change requires restart)
max_locks_per_transaction = 256    # min 10
escape_string_warning = off
standard_conforming_strings = off
include_dir = 'conf.d'            # include files ending in '.conf' from
online_analyze.threshold = 50
online_analyze.scale_factor = 0.1
online_analyze.enable = off
online_analyze.verbose = off
online_analyze.local_tracking = on
online_analyze.min_interval = 10000
online_analyze.table_type = 'temporary'

(191) о каких рекомендациях речь? Не тех ли, что для верстии 9.2-9.4?

(192) у меня послабее
Intel Core i7 4770K @ 3.50GHz, 16 ГБ DDR3 @ 665 МГц

поставил PostgreSQL Database Server 11.5-1.1C(x64), работает вроде быстро :)

в файле postgresql.conf оставил все как есть, изменил только

max_connections = 20
shared_buffers = 2GB
temp_buffers = 256MB
work_mem = 1GB
maintenance_work_mem = 1GB
max_worker_processes = 8
max_parallel_workers_per_gather = 4
wal_sync_method = open_datasync
wal_buffers = 16MB
max_wal_size = 1GB
min_wal_size = 512MB
checkpoint_completion_target = 0.9
random_page_cost = 4.0
effective_cache_size = 4GB
default_statistics_target = 300
max_locks_per_transaction = 250 - вот это последнее изменения, после которого получилось без ошибок делать бекап/ресторе с помощью pgAdmin (по умолчанию было 100 и ошибка "Out of shared memory: You might need to increase max_locks_per_transaction")


Везде, я смотрю, все меняют и пишут про свои параметры.

А нет ли какой то зависимости от памяти, ядер и тд?
Или какой то программы, или экселевского файла, в котором вносишь данные сервера,
а формулы рассчитывают и дают значения, которые просто ставишь в postgresql.conf? :)

(194) https://pgtune.leopard.in.ua/#/

(195) сайту 100 лет в обед... возможно часть настроек неактуальная и уж точно для точного тюнинга он не пригоден.

К примеру Алексей Лустин настаивал для ЗУП указывать в настройках "более агрессивный автовакуум".

(195) сделал, оказалось отличие в

сайт                                    у меня
shared_buffers = 512MB            shared_buffers = 2GB
checkpoint_completion_target = 0.5    checkpoint_completion_target = 0.9
work_mem = 11286kB            work_mem = 1GB
min_wal_size = 100MB            min_wal_size = 512MB

и я еще добавил себе
temp_buffers = 256MB
wal_sync_method = open_datasync

(197) wal_sync_method

в доке есть описание специальной утилиты в составе постгреса. Запускаешь ее , рна тестирует дисковую и показывает какой лучше wal_sync_method

ошибка в больничных листах ЗГУ
В 11.5-1.1С опять проявляется эта ошибка, в 10.10 такого нет.
Хотел уже поставить в качестве рабочей СУБД, вовремя обнаружилось. Так что, пока повременю. Сообщил о ситуации франчу, обещали отписать в 1С. В прошлый раз довольно быстро поправили.

(199) а что за ошибка?

У меня на сервере работает
Зарплата и управление персоналом, редакция 3.1 (3.1.11.133)
Бухгалтерия предприятия, редакция 3.0 (3.0.73.60)

Неправильно вставилось
ошибка в больничных листах ЗГУ

(201) Может так: ошибка в больничных листах ЗГУ

(202) Да, спасибо.

Добрый день.

При перезапуске службы сервера в лог-файле пишется

< 2019-11-30 07:48:37.026 MSK >LOG:  received fast shutdown request
< 2019-11-30 07:48:37.064 MSK >LOG:  aborting any active transactions
< 2019-11-30 07:48:37.082 MSK >LOG:  background worker "logical replication launcher" (PID 2604) exited with exit code 1
< 2019-11-30 07:48:37.086 MSK >LOG:  shutting down
< 2019-11-30 07:48:38.191 MSK >LOG:  database system is shut down
< 2019-11-30 07:48:41.276 MSK >LOG:  database system was shut down at 2019-11-30 07:48:37 MSK
< 2019-11-30 07:48:41.331 MSK >LOG:  database system is ready to accept connections



Что значит следующая строка? Если это не нормально, то как ипсравить?

background worker "logical replication launcher" (PID 2604) exited with exit code 1

(204) Процесс завершился с кодом 1. То, что он завершился в процессе погашения службы - это нормально

(205) а PID 2604 смотрю, все время разный.

(206) Я тебе сейчас страшную вещь скажу, ты не пугайся, только сядь поудобней и держись покрепче...
PID - это Process Identificator, он при каждом запуске процесса меняется...

(207) держался, не упал, спасибо :).

Выпустили обновление 11.5-7.1C. Поправили ошибку с больничными листами в ЗГУ и  ЗУП(см. (199) и ссылку в (202) ).

(204) Достаточно установить max_logical_replication_workers=0 и сообщение выводиться не будет. Вернее, не будут запускаться процессы для логической репликации.