SQL Error [53200]: ОШИБКА: нехватка разделяемой памяти Подсказка: Возможно, следует увеличить параметр max_locks_per_transaction
При выполнении запросов на БД (Postgres) возникла ошибка:
24.02.21 13:50:38.219,main,ERROR,ExecSql,null
com.bssys.db.jdbc.DBSQLException: ОШИБКА: нехватка разделяемой памяти
Подсказка: Возможно, следует увеличить параметр max_locks_per_transaction.
Подробная информация по параметру здесь. Коротко ниже:
max_locks_per_transaction (integer)
Этот параметр управляет средним числом блокировок объектов, выделяемым для каждой транзакции; отдельные транзакции могут заблокировать и больше объектов, если все они умещаются в таблице блокировок.
Значение по умолчанию = 64
рядом также находится параметр max_pred_locks_per_transaction (integer)
В файле postgresql.conf (Postgres/data/) указано так:
#———————————————————————-
# LOCK MANAGEMENT
#———————————————————————-
#deadlock_timeout = 1s
#max_locks_per_transaction = 64 # min 10
# (change requires restart)
#max_pred_locks_per_transaction = 64 # min 10
# (change requires restart)
Изменил на это значение:
#———————————————————————-
# LOCK MANAGEMENT
#———————————————————————-
#deadlock_timeout = 1s
max_locks_per_transaction = 256 # min 10
# (change requires restart)
max_pred_locks_per_transaction = 1000 # min 10
# (change requires restart)
P.S. После изменения убрать символ «#» в начале строки
Популярные сообщения из этого блога
TRUNCATE / DELETE / DROP или как очистить таблицу
ИМЕЕМ: Таблица MSG (сообщения) с большим количеством записей. SQL> CREATE TABLE msg (id INTEGER NOT NULL PRIMARY KEY, description CHAR (50) NOT NULL, date_create DATE); ЗАДАЧА: Необходимо очистить таблицу от данных РЕШЕНИЕ: Для решения данной задачи есть несколько способов. Ниже описание и пример каждого из них. Способ №1 — используем DELETE Самый простой способ (первый вариант) — выполнение оператора удаления записи. При его выполнении вы будете видеть результат (сколько записей удалено). Удобная штука когда необходимо точно знать и понимать правильные ли данные удалены. НО имеет недостатки перед другими вариантами решения поставленной задачи. SQL> DELETE FROM msg; —Удалит все строки в таблице SQL> DELETE FROM msg WHERE date_create = ‘2019.02.01’; —Удалит все строки у которых дата создания «2019.02.01» Способ №2 — используем TRUNCATE Использование оператора DML для очистки всех строк в та
Linux (РедОС). Сброс пароля
Используется ОС РедОС 7.1, которая установлена в VBox. В процессе установки ОС, был задан только пароль для «root», дополнительных пользователей не создавалось. В рекомендациях на сайте производителя ОС указано: Помимо администратора РЕД ОС (root) в систему необходимо добавить, по меньшей мере, одного обычного пользователя. Работа от имени администратора РЕД ОС считается опасной (можно по неосторожности повредить систему), поэтому повседневную работу в РЕД ОС следует выполнять от имени обычного пользователя, полномочия которого ограничены. После перезапуска и попытке войти в систему под root, система выдает сообщение «Не сработало .попробуйте еще раз». Поэтому для решения проблемы было решено создать пользователя, для этого выполняем такие действия: После загрузки, в момент выбора системы, быстро нажимаем стрелки вверх и вниз (приостанавливаем обратный отсчет). Выбираем ядро и нажимаем «e». Находим строку, которая относится к ядру: здесь будет ряд «boot parameter
КБК. КВФО — Код вида финансового обеспечения (деятельности)
НПА: Приказ Минфина России от 01.12.2010 N 157н Письмо Минфина России от 18 января 2018 г. N 02-06-10/2715 В целях организации и ведения бухгалтерского учета, утверждения Рабочего плана счетов применяются следующие коды вида финансового обеспечения (деятельности): для государственных (муниципальных) учреждений, организаций, осуществляющих полномочия получателя бюджетных средств, финансовых органов соответствующих бюджетов и органов, осуществляющих их кассовое обслуживание: 1 — деятельность, осуществляемая за счет средств соответствующего бюджета бюджетной системы Российской Федерации (бюджетная деятельность); 2 — приносящая доход деятельность (собственные доходы учреждения); 3 — средства во временном распоряжении; 4 — субсидии на выполнение государственного (муниципального) задания; 5 — субсидии на иные цели; 6 — субсидии на цели осуществления капитальных вложений; 7 — средства по обязательному медицинскому страхованию; для отражения органами Федерального казн
ЭС с ЦБ РФ. РЕКВИЗИТНЫЙ СОСТАВ ЭС
4 РЕКВИЗИТНЫЙ СОСТАВ ЭС ED101 Платежное поручение ED103 Платежное требование ED104 Инкассовое поручение ED105 Платежный ордер ED107 Поручение банка ED108 Платежное поручение на общую сумму с реестром ED109 Банковский ордер ED110 ЭПС сокращенного формата ED111 Мемориальный ордер в электронном виде ED113 Выставляемое на оплату платежное требование ED114 Выставляемое на оплату инкассовое поручение ED201 Извещение о результатах контроля ЭС (пакета ЭС) ED202 Запрос по ЭПС (пакету ЭПС) ED203 Запрос по группе ЭПС ED204 Запрос об отзыве/аннулировании ЭС (пакета ЭС). ED205 Извещение о состоянии ЭПС (пакета ЭПС) ED206 Подтверждение
При создании резервных копий БД обнаружил, что некоторые копии не создались. При ручном запуске команды на создание файла бекапа увидел ошибку при выполнении запроса:
ОШИБКА: нехватка разделяемой памяти
Там же, собственно, есть и подсказка: следует увеличить параметр max_locks_per_transaction.
Этот параметр управляет средним числом блокировок объектов, выделяемым для каждой транзакции; отдельные транзакции могут заблокировать и больше объектов, если все они умещаются в таблице блокировок.
Значение по умолчанию = 64
В папке с данными Postgres необходимо найти файл postgresql.conf и найти строку с параметром max_locks_per_transaction. Ее следует раскомментировать и указать, например, 256.
SQL Error [53200]: ОШИБКА: нехватка разделяемой памяти Подсказка: Возможно, следует увеличить параметр max_locks_per_transaction
При выполнении запросов на БД (Postgres) возникла ошибка:
24.02.21 13:50:38.219,main,ERROR,ExecSql,null
com.bssys.db.jdbc.DBSQLException: ОШИБКА: нехватка разделяемой памяти
Подсказка: Возможно, следует увеличить параметр max_locks_per_transaction.
Подробная информация по параметру здесь. Коротко ниже:
max_locks_per_transaction (integer)
Этот параметр управляет средним числом блокировок объектов, выделяемым для каждой транзакции; отдельные транзакции могут заблокировать и больше объектов, если все они умещаются в таблице блокировок.
Значение по умолчанию = 64
рядом также находится параметр max_pred_locks_per_transaction (integer)
В файле postgresql.conf (Postgres/data/) указано так:
#———————————————————————-
# LOCK MANAGEMENT
#———————————————————————-
#deadlock_timeout = 1s
#max_locks_per_transaction = 64 # min 10
# (change requires restart)
#max_pred_locks_per_transaction = 64 # min 10
# (change requires restart)
Изменил на это значение:
#———————————————————————-
# LOCK MANAGEMENT
#———————————————————————-
#deadlock_timeout = 1s
max_locks_per_transaction = 256 # min 10
# (change requires restart)
max_pred_locks_per_transaction = 1000 # min 10
# (change requires restart)
P.S. После изменения убрать символ «#» в начале строки
Популярные сообщения из этого блога
КБК. КВФО — Код вида финансового обеспечения (деятельности)
НПА: Приказ Минфина России от 01.12.2010 N 157н Письмо Минфина России от 18 января 2018 г. N 02-06-10/2715 В целях организации и ведения бухгалтерского учета, утверждения Рабочего плана счетов применяются следующие коды вида финансового обеспечения (деятельности): для государственных (муниципальных) учреждений, организаций, осуществляющих полномочия получателя бюджетных средств, финансовых органов соответствующих бюджетов и органов, осуществляющих их кассовое обслуживание: 1 — деятельность, осуществляемая за счет средств соответствующего бюджета бюджетной системы Российской Федерации (бюджетная деятельность); 2 — приносящая доход деятельность (собственные доходы учреждения); 3 — средства во временном распоряжении; 4 — субсидии на выполнение государственного (муниципального) задания; 5 — субсидии на иные цели; 6 — субсидии на цели осуществления капитальных вложений; 7 — средства по обязательному медицинскому страхованию; для отражения органами Федерального казн
TRUNCATE / DELETE / DROP или как очистить таблицу
ИМЕЕМ: Таблица MSG (сообщения) с большим количеством записей. SQL> CREATE TABLE msg (id INTEGER NOT NULL PRIMARY KEY, description CHAR (50) NOT NULL, date_create DATE); ЗАДАЧА: Необходимо очистить таблицу от данных РЕШЕНИЕ: Для решения данной задачи есть несколько способов. Ниже описание и пример каждого из них. Способ №1 — используем DELETE Самый простой способ (первый вариант) — выполнение оператора удаления записи. При его выполнении вы будете видеть результат (сколько записей удалено). Удобная штука когда необходимо точно знать и понимать правильные ли данные удалены. НО имеет недостатки перед другими вариантами решения поставленной задачи. SQL> DELETE FROM msg; —Удалит все строки в таблице SQL> DELETE FROM msg WHERE date_create = ‘2019.02.01’; —Удалит все строки у которых дата создания «2019.02.01» Способ №2 — используем TRUNCATE Использование оператора DML для очистки всех строк в та
Linux (РедОС). Сброс пароля
Используется ОС РедОС 7.1, которая установлена в VBox. В процессе установки ОС, был задан только пароль для «root», дополнительных пользователей не создавалось. В рекомендациях на сайте производителя ОС указано: Помимо администратора РЕД ОС (root) в систему необходимо добавить, по меньшей мере, одного обычного пользователя. Работа от имени администратора РЕД ОС считается опасной (можно по неосторожности повредить систему), поэтому повседневную работу в РЕД ОС следует выполнять от имени обычного пользователя, полномочия которого ограничены. После перезапуска и попытке войти в систему под root, система выдает сообщение «Не сработало .попробуйте еще раз». Поэтому для решения проблемы было решено создать пользователя, для этого выполняем такие действия: После загрузки, в момент выбора системы, быстро нажимаем стрелки вверх и вниз (приостанавливаем обратный отсчет). Выбираем ядро и нажимаем «e». Находим строку, которая относится к ядру: здесь будет ряд «boot parameter
ТФФ 34.0. Полный перечень документов альбома ТФФ (Таблица 2)
Для удобства и поиска информации по томам, маркерам и обозначении версии ТФФ. Таблица актуальна — версия 34.0 — (дата начала действия с 01.01.2023 г.) Ссылки на предыдущие версии форматов: ТФФ 33.0 — https://albafoxx.blogspot.com/2021/01/320-2.html ТФФ 32.0 — https://albafoxx.blogspot.com/2020/01/310-2.html ТФФ 31.0 — https://albafoxx.blogspot.com/2020/01/310-2.html ТФФ 30.0 — https://albafoxx.blogspot.com/2019/12/300-2.html ТФФ 29.0 — https://albafoxx.blogspot.com/2019/05/290-2.html ТФФ 28.0 — https://albafoxx.blogspot.com/2019/04/2.html Наименование документа (справочника) Маркер Номер версии ТФО документа № тома Казначейское уведомление SU TXSU190101 2 Расходное расписание, Реестр расходных расписаний AP TXAP190101 1 Перечень целевых субсидий TL TXTL170101 1 Уведомление (протокол), Ин
ТФФ 33.0. Полный перечень документов альбома ТФФ (Таблица 2)
Для удобства и поиска информации по томам, маркерам и обозначении версии ТФФ. Таблица НЕ актуальна — версия 33.0 — (дата начала действия с 01.01.2022 г.) с 01.01.2023 г действует новая версия ТФФ — версия 34.0 Ссылки на предыдущие версии форматов: ТФФ 32.0 — https://albafoxx.blogspot.com/2020/01/310-2.html ТФФ 31.0 — https://albafoxx.blogspot.com/2020/01/310-2.html ТФФ 30.0 — https://albafoxx.blogspot.com/2019/12/300-2.html ТФФ 29.0 — https://albafoxx.blogspot.com/2019/05/290-2.html ТФФ 28.0 — https://albafoxx.blogspot.com/2019/04/2.html Наименование документа (справочника) Маркер Номер версии ТФО документа № тома Казначейское уведомление SU TXSU190101 2 Уведомление (протокол), Информация о непрошедших контроль документах в ППО Федерального казначейства PT TXPT170101 2 Выписка из лицевого счета главного распорядителя (распор
Johan
06.09.17 — 08:02
Добрый день,прошу помощи в решении проблемы
пользую 1с 8.3.9.2309 + PostgreSql 9.4.2-1.1C происходит ошибка при загрузке базы dt ,ошибка 53200 error out of memory detail failed on request of size 536870912
ОС windows server 2016 standard,аналогичная проблема и на других ос
Пробовал менять настройки конфига pg,сейчас они такие
Это из основных как я полагаю интересующих :
shared_buffers = 64MB # min 128kB
temp_buffers = 256MB # min 800kB
work_mem = 128MB # min 64kB
maintenance_work_mem = 256MB # min 1MB
effective_cache_size = 6GB
——————————————
Всего оперативной памяти 16gb
Причём конкретно только одна база не загружается (она исправна,её тестировал БП 2.0)
ещё пробовал увеличить файл подкачки на диске С
Помогите кто сталкивался с такой же проблемой?кто её решил?
Arh01
1 — 06.09.17 — 08:10
разрядность PostgreSql какая?
Johan
2 — 06.09.17 — 08:12
(1) 64 разрядная как и windows server
Johan
3 — 06.09.17 — 08:21
В логе вот что пишет:
pg_authid_rolname_index: 1024 total in 1 blocks; 552 free (0 chunks); 472 used
MdSmgr: 8192 total in 1 blocks; 6544 free (0 chunks); 1648 used
LOCALLOCK hash: 8192 total in 1 blocks; 2880 free (0 chunks); 5312 used
Timezones: 79320 total in 2 blocks; 5968 free (0 chunks); 73352 used
ErrorContext: 8192 total in 1 blocks; 8176 free (0 chunks); 16 used
2017-09-04 18:55:43 MSK ERROR: out of memory
2017-09-04 18:55:43 MSK DETAIL: Failed on request of size 536870912.
2017-09-04 18:55:43 MSK CONTEXT: COPY config, line 328, column binarydata
2017-09-04 18:55:43 MSK STATEMENT: COPY Config FROM STDIN BINARY
rphosts
4 — 06.09.17 — 08:21
попробуй в work_mem указать немного больше чем от тебя просят
Johan
5 — 06.09.17 — 08:22
ставил 256 и 512
rphosts
6 — 06.09.17 — 08:22
и да, этот ДТ куда-то вообще загружается? Он точно не битый?
rphosts
7 — 06.09.17 — 08:23
(5) переведи «on request of size 536870912»
Johan
8 — 06.09.17 — 08:25
(6) Да как файловая база он загружается
Johan
9 — 06.09.17 — 08:27
(6) и точно не битый делал тестирование и исправление и chdbfl,без ошибок
Johan
10 — 06.09.17 — 08:30
(7)размер по запросу 536870912,полагаю что не хватает памяти загрузить какую то таблицу
Johan
11 — 06.09.17 — 08:31
а где её увеличить!?или может какой то другой параметр нужно увеличить
rphosts
12 — 06.09.17 — 08:34
(11) 536 больше 512?
Johan
13 — 06.09.17 — 08:36
(12) я понял к чему ты,я пробовал и 1024 ставить
Johan
14 — 06.09.17 — 08:36
(12) но вот только не везде
Johan
15 — 06.09.17 — 08:39
Попробую work_mem выставить > 536 ,но смогу попробовать вечером
rphosts
16 — 06.09.17 — 08:52
(15) сделай сразу побольше чтобы наверняка
Johan
17 — 06.09.17 — 09:07
(16) да 1024 поставлю,отпишусь по результату
Asmody
18 — 06.09.17 — 09:20
и temp_buffers тоже.
Asmody
19 — 06.09.17 — 09:30
shared_buffers рекомендуется делать побольше. 1/4 — 1/3 RAM.
maintenance_work_mem в 1/2 RAM или больше (до RAM-shared_buffers)
Johan
20 — 06.09.17 — 09:40
(19) если не ошибаюсь то пробовал я ставить и больше 1 gb в
shared_buffers или temp_buffers служба pg перестаёт запускаться
Johan
21 — 06.09.17 — 11:01
(16) Попробывал,выставить 1024 work_mem,shared_buffers,temp_buffers ошибка всё равно выходит
Johan
22 — 06.09.17 — 11:04
Увидел вот какой момент,в свойствах Pg есть строка версии где написано PostgreSQL 9.4.2,complited by Visual C++ build 1500, 32-bit
Johan
23 — 06.09.17 — 11:06
мне эта строка не нравится,типа используются компоненты Visual C++ 32 бита,посмотрел на давно созданном сервере тоже на pg там 64 стоит м.б дело в этом!?
Johan
24 — 06.09.17 — 11:26
Похоже что да,вроде как ура..грузит ,но ошибку не выкидывает
Johan
25 — 06.09.17 — 11:36
победа,парни дико извиняюсь,3 дня не в ту сторону смотрел,не тот дистрибутив поставил поставил общий,а надо было postgresql-9.4.2-1.1C_x64
Arh01
26 — 06.09.17 — 11:49
(25) Теперь научился отличать приложения х64 от х86?
dezss
27 — 06.09.17 — 11:55
(12) они равны
Johan
28 — 06.09.17 — 12:35
(26) Да,я поставил не посмотрев,а в описании в pg и сервис написано 64 Bit,а вот когда увидел строку версии ,тогда меня смутило
I have a query that inserts a given number of test records.
It looks something like this:
CREATE OR REPLACE FUNCTION _miscRandomizer(vNumberOfRecords int)
RETURNS void AS $$
declare
-- declare all the variables that will be used
begin
select into vTotalRecords count(*) from tbluser;
vIndexMain := vTotalRecords;
loop
exit when vIndexMain >= vNumberOfRecords + vTotalRecords;
-- set some other variables that will be used for the insert
-- insert record with these variables in tblUser
-- insert records in some other tables
-- run another function that calculates and saves some stats regarding inserted records
vIndexMain := vIndexMain + 1;
end loop;
return;
end
$$ LANGUAGE plpgsql;
When I run this query for 300 records it throws the following error:
********** Error **********
ERROR: out of shared memory
SQL state: 53200
Hint: You might need to increase max_locks_per_transaction.
Context: SQL statement "create temp table _counts(...)"
PL/pgSQL function prcStatsUpdate(integer) line 25 at SQL statement
SQL statement "SELECT prcStatsUpdate(vUserId)"
PL/pgSQL function _miscrandomizer(integer) line 164 at PERFORM
The function prcStatsUpdate looks like this:
CREATE OR REPLACE FUNCTION prcStatsUpdate(vUserId int)
RETURNS void AS
$$
declare
vRequireCount boolean;
vRecordsExist boolean;
begin
-- determine if this stats calculation needs to be performed
select into vRequireCount
case when count(*) > 0 then true else false end
from tblSomeTable q
where [x = y]
and [x = y];
-- if above is true, determine if stats were previously calculated
select into vRecordsExist
case when count(*) > 0 then true else false end
from tblSomeOtherTable c
inner join tblSomeTable q
on q.Id = c.Id
where [x = y]
and [x = y]
and [x = y]
and vRequireCount = true;
-- calculate counts and store them in temp table
create temp table _counts(...);
insert into _counts(x, y, z)
select uqa.x, uqa.y, count(*) as aCount
from tblSomeOtherTable uqa
inner join tblSomeTable q
on uqa.Id = q.Id
where uqa.Id = vUserId
and qId = [SomeOtherVariable]
and [x = y]
and vRequireCount = true
group by uqa.x, uqa.y;
-- if stats records exist, update them; else - insert new
update tblSomeOtherTable
set aCount = c.aCount
from _counts c
where c.Id = tblSomeOtherTable.Id
and c.OtherId = tblSomeOtherTable.OtherId
and vRecordsExist = true
and vRequireCount = true;
insert into tblSomeOtherTable(x, y, z)
select x, y, z
from _counts
where vRecordsExist = false
and vRequireCount = true;
drop table _counts;
end;
$$ LANGUAGE plpgsql;
It looks like the error is a result of a memory building up somewhere but since I create temp table, use it and drop right away (thus to my understanding releasing memory), I don’t see how that would be possible.
Update
I updated prcStatsUpdate function to represent the actual function that I have. I just replaced table and column names to be something generic.
The reason I didn’t post this first time is that it’s mostly very simple sql operations and I assumed there could not be any issues with it.
Also, where do you start line counting from? It says error is on line 25, but that just can’t be true since line 25 is a condition in the where clause if you start counting from the beginning. Do you start counting from begin?
Any ideas?
Доброго дня.
Сегодня получил такую ошибку в логах. До этого сервер крутился без рестарта где-то месяца три, база не то чтобы очень большая, но в некоторых таблицах сотни тысяч строк. Увеличил этот самый «max_locks_per_transaction», поднял «shared_buffers» и «work_mem», перезапустил postgres, проблема исчезла. Но навсегда ли?
Было:
shared_buffers = 128MB # min 128kB
work_mem = 4MB # min 64kB
temp_buffers = 8MB # min 800kB
max_locks_per_transaction = 64 # min 10Стало:
shared_buffers = 256MB # min 128kB
work_mem = 16MB # min 64kB
temp_buffers = 32MB # min 800kB
max_locks_per_transaction = 1024 # min 10Выполнение запроса к pg_locks вменяемой информации не дало (или я просто не умею читать между строк).
Собственно, вопрос следующий: куда копать, возможно, настроить доп. логирование? Я хочу точно понять, почему это появилось, дабы предотвратить дальнейшие рецидивы. Может, у меня кривые запросы, которые продуцируют дедлоки? Или просто увеличение объема бд требует увеличение объема выделенной памяти? Еще что-то?
Заранее спасибо.
I am getting numerous of the following error message when testing a patch on Postgres:
PDOException: SQLSTATE[53200]: Out of memory: 7 ERROR: out of shared memory HINT: You might need to increase max_locks_per_transaction
I can’t see any way that the patch could cause these.
Example: https://www.drupal.org/pift-ci-job/1112291
Comments
- Log in or register to post comments
I suggest increasing max_locks_per_transaction to see if that fixes it. It may be that more locks are needed with this patch because it adds foreign keys. The patch used to pass Postgres testing, but then stopped.
- Log in or register to post comments
- Log in or register to post comments
Is there anything I can do to help advance this?
- Log in or register to post comments
| Project: | DrupalCI: Test Runner | » DrupalCI: Environments |
| Component: | Jobs and Job Handling | » PHP Containers |
There is a new postgres 9.5 container — I just queued up a test on the posted issue to see if the problem is still there.
If it is, we can look at the postgres config for the containers, which is in the drupalci_environments repository.
Im moving this there now.
- Log in or register to post comments
Thanks very much. The patch passes with Postgres 9.5. Is compatibility with Postgres 9.1 still required for a patch to be accepted into core? The answer to that will determine whether Postgres 9.1 testing needs to be fixed.
- Log in or register to post comments
- Log in or register to post comments
-
Уважаемые, у меня возникла следующая проблема: при попытке произвести обмен данными, как мы уже неоднократно это делали, вдруг возникла ошибка следующего содержания
Ошибка СУБД
Error: Out of shared memory
Hint: You may need increase max_lock_per_transaction.Пробовал переписать настройки в postgre.conf
shared_buffers = 48MB (по умолчанию 27)
max_lock_per_transaction = 250( по умолчанию 150)
max_connections я уменьшил со 100 до 50
Результат остался тот же, да и на одном из форумов PostgreSQL прочитал что так можно разрушить базу, поэтому эксперименты свои решил прекратить, может кто-нибудь сталкивался с подобной проблемой, подскажите, что делать, я ума не приложу!!!
1C 8.1.11.64
PostgreSQL 8.2.4-3.1C -
Offline
BabySG
Администраторы
Команда форума
Администратор- Регистрация:
- 10 июн 2007
- Сообщения:
- 11.853
- Симпатии:
- 18
- Баллы:
- 29
Где-то я слышал, что такое может быть, когда слишком много таблиц одновременно задействовано…
Обмен какой идет? Попробуйте обмениваться более мелкими порциями данных.
-
более мелкими порциями обмениваться не получиться, что касается обмена, то я не в курсе, бухгалтерия говорит это автообмен, который вроде как должен производиться раз в сутки, но пока мы производим его максимум пару раз в неделю, при чем выявляется последовательность, что ошибка возникла сразу после обновления 1С платформы до версии 1.11.64, до этого все работало долго, но работало. у нас в штате нет 1С программиста, а я в этом деле не особо силен…..какие есть мысли?
-
Offline
BabySG
Администраторы
Команда форума
Администратор- Регистрация:
- 10 июн 2007
- Сообщения:
- 11.853
- Симпатии:
- 18
- Баллы:
- 29
Последняя версия 11.67 — стоит обновиться
Давайте поподробнее, как делается обмен и какие правила настроены.
А то испорченный телефон получается. -
Offline
Kadra
- Регистрация:
- 17 фев 2009
- Сообщения:
- 1
- Симпатии:
- 0
- Баллы:
- 1
Аналогичная проблема.
Postgres 8.3.3-2.1C
1С 8.1.13.41
УПП 1.2.20.1Распределенная информационная база. Размер базы примерно 3Gb. Полный обмен файловый. Обычный размер выгружаемого файла 1м. В центральной базе сделали проведение по партиям за месяц. Файл выгрузки получился 11м. При загрузке в удаленную базу выдало ошибку.
Ошибка СУБД
Error: Out of shared memory
Hint: You may need increase max_lock_per_transaction.
На удаленной машине установлен пень 4-2гигагерца 2 гигабайта памяти.
В настройках постгри
effective_cache_size = 1512MB
остальное по дефолту.Буквально 2 недели назад делал обновление конфигурации центральной базы. Файл выгрузки был 40 метров примерно. Обмены прошли нормально. А тут вот такая заковырка.
MurCode
- Форумы
- Поиск
- О проекте
Почему бывает ОШИБКА: нехватка разделяемой памяти
trom
Дата: 27.10.2012 09:34:37
Предположительно все началась после того как я начал использовать pg_try_advisory_lock(
Текст ошибки в Pgadmin такой
| автор |
|---|
| ПРЕДУПРЕЖДЕНИЕ: нехватка разделяемой памяти
ОШИБКА: нехватка разделяемой памяти ********** Ошибка ********** ОШИБКА: нехватка разделяемой памяти |
После использования pg_try_advisory_lock(
я делаю
$Query = "SELECT pg_advisory_unlock_all();" $result = _SQLQuery($Conn, $Query)
и потом
_SQLDisconnect($Conn)
Может еще что-то нужно добавить или убрать ?
В программе которая работает с базой ошибка возникает при выполнении запроса в котором использую pg_try_advisory_lock(
К базе конектюсь используя ODBC драйвер может он неправильно работает с блокировками ?
Maxim Boguk
Дата: 27.10.2012 10:57:20
| trom | ||
|---|---|---|
| Предположительно все началась после того как я начал использовать pg_try_advisory_lock(
Текст ошибки в Pgadmin такой
После использования pg_try_advisory_lock( $Query = "SELECT pg_advisory_unlock_all();" $result = _SQLQuery($Conn, $Query) и потом _SQLDisconnect($Conn) Может еще что-то нужно добавить или убрать ? |
вы слишком много advisory_locks в транзакции делаете… этот механизм не предназначен для установки сотен локов
trom
Дата: 27.10.2012 11:05:16
Maxim Boguk,
А Что посоветуете для такого запроса
Local $Query = "SELECT * FROM base WHERE status=1 And pg_try_advisory_lock(id) limit 25 ;"
То есть нужно заблокировать в таблице 25 записей.
Проблемы начинаются не сразу, клиентская прога может нормально работать пару дней, а потом начинаются ошибки
Maxim Boguk
Дата: 27.10.2012 13:20:02
| trom |
|---|
| Maxim Boguk,
А Что посоветуете для такого запроса Local $Query = "SELECT * FROM base WHERE status=1 And pg_try_advisory_lock(id) limit 25 ;" То есть нужно заблокировать в таблице 25 записей. |
SELECT pg_advisory_unlock_all()
надо вызвать не перед началом обработки
а сразу после окончания обработки этих 25 записей…
у вас где то advisory_locks текут…
проще всего посмотреть в pg_locks сколько и чего у вас там висит может понятнее будет…
вообще:
http://www.postgresql.org/docs/9.2/static/explicit-locking.html#ADVISORY-LOCKS
>>Both advisory locks and regular locks are stored in a shared memory pool whose size is defined by the configuration variables max_locks_per_transaction and max_connections. Care must be taken not to exhaust this memory or the server will be unable to grant any locks at all. This imposes an upper limit on the number of advisory locks grantable by the server, typically in the tens to hundreds of thousands depending on how the server is configured.
И внимательно прочтите что там написанно дальше… в районе:
>>In the above queries, the second form is dangerous because the LIMIT is not guaranteed to be applied before the locking function is executed. This might cause some locks to be acquired that the application was not expecting, and hence would fail to release (until it ends the session). From the point of view of the application, such locks would be dangling, although still viewable in pg_locks.
индексы
Дата: 27.10.2012 13:26:54
| trom |
|---|
| Maxim Boguk,
А Что посоветуете для такого запроса Local $Query = "SELECT * FROM base WHERE status=1 And pg_try_advisory_lock(id) limit 25 ;" То есть нужно заблокировать в таблице 25 записей. |
trom, если вы читали обсуждения механизма advisory_lock, то длолжны понимать , что при низкой селективности по статус и/или отсутствии индекса по нему (status), вы получите блокировку всех ключей таблицы (и, вероятно, часто — даже не только тех, которые попадают в WHERE status=1)
поэтому вам надо посмотреть сначала на план запроса — на предмет того, что лимит пытается пользовать index scan + filter, а не накладывается потом на полный filter/ (т.е. строка вида
Filter: pg_try_advisory_lock((tableoid)::integer, id)
должна быть последней строкой следующего уровня вложенности плана в LIMIT (см. пример, который вам давали)
или можете руками организовать перебор id, с проверкой каждого на pg_try_advisory_lock(id) и отсечкой перебора сразу, как наберёте именно 25. (WITH RECURSIVE …)
ну и топорный вариант- набираете 25 так, как вначале (т.е. на деле лоча все ключи таблицы — где и можете получить сообщение о нехватке памяти) в массив , сразу же освобождаете ВСЁ, и только потом блокируете 25 точнёхонько из набранного массива.
PS и ещё: LIMIT имеет смысл накладывать вдоль одного и того же ORDER BY-я. например вдоль (технологического) индекса (status,id)
trom
Дата: 27.10.2012 16:14:49
Maxim Boguk,
| автор |
|---|
| SELECT pg_advisory_unlock_all() надо вызвать не перед началом обработки а сразу после окончания обработки этих 25 записей… |
Я так и делаю Maxim Boguk pg_advisory_unlock_all() вызываю в самом конце, а потом еще и _SQLDisconnect($Conn)
| автор |
|---|
| проще всего посмотреть в pg_locks сколько и чего у вас там висит может понятнее будет… |
А не подскажете где это посмотреть, интересно было бы глянуть сколько у меня блокировок, сейчас тестирую все в один поток что будет при нескольких потоках непонятно
индексы,
То есть мне нужно сделать индексы на все поля которые идут после WHERE ? у меня там по двум полям идет выборка
Или второй вариант который если я правильно понял выглядит так, сделать цикл с помощью клиентской проги и каждый раз выбирать по 1 записи записывая все в массив, тогда и индексы не нужны и все надежно будет ?
Второй вариант мне нравиться больше но непонятно куда вставлять WITH RECURSIVE, я пока представляю это простейший цикл на 25 запросов к базе и запись всего в массив, мне пока нужен самый простой и надежный вариант, даже в ущерб производительности
индексы
Дата: 27.10.2012 18:14:03
| trom |
|---|
| индексы, То есть мне нужно сделать индексы на все поля которые идут после WHERE ? у меня там по двум полям идет выборка |
какбе нет.
нужно понимать, что такое [множественные] отношения порядка на мн-ве
и какое именно отношение порядка оптимально обслуживает тот или иной запрос (в совокупности WHERE / [group by] / ORDER BY
и для этого отношения и строить индекс («альфабитный предметный указатель»)
евпочя
| trom |
|---|
| Или второй вариант который если я правильно понял выглядит так, сделать цикл с помощью клиентской проги и каждый раз выбирать по 1 записи записывая все в массив, тогда и индексы не нужны и все надежно будет ? Второй вариант мне нравиться больше но непонятно куда вставлять WITH RECURSIVE, я пока представляю это простейший цикл на 25 запросов к базе и запись всего в массив, мне пока нужен самый простой и надежный вариант, даже в ущерб производительности |
если по одной, и именно клиентом, то WITH RECURSIVE вам не нужно.
нужны PREPARE параметрические запросы вида
SELECT * from table where status=$1 AND id>$2 LIMIT 1;--выборка SELECT pg_try_advisory_lock($1);--проба лока
и гоняя их в цикле добираться до незалоченных ещё id
WITH RECURSIVE позволяет всё это имитировать внутри одного sql-стейтмента, и/или внутри хранимки. (т.е. серверного а не клиентского кода).
индексы
Дата: 27.10.2012 18:20:45
SELECT * from table where status=$1 AND id>$2 ORDER BY id LIMIT 1;--выборка -- поправил SELECT pg_try_advisory_lock($1);--проба лока
trom
Дата: 27.10.2012 21:19:18
индексы,
Тогда еще момент допустим в базе не набираеться 25 записей, а только 10 или вообще 0
Как определить что в базе больше нет ничего, клиента устроит если ему дадут 10 записей или 0 при условии что больше в базе нет или они заблокированы другими клиентами.
индексы
Дата: 28.10.2012 10:16:20
| trom |
|---|
| индексы,
Тогда еще момент допустим в базе не набираеться 25 записей, а только 10 или вообще 0 |
trom,
вы издеваетесь ?
сколько вам лет ?
каков уровень вашего образования ?
вы когда-либо пытались думать мозгом ?
у вас есть опыт планирования и выполнения мелких тестов ?
вы можете на свои «вопросы» посмотреть как на задачу для микро-теста
который вам надо накидать на коленке за 5 (пять) минут
и гоняя его (микротест) руками, обдумать его результаты мозгом ?
не альтернативно здоровы ли вы ?
следует ли общаться с вами как с альтернативно разумным ?
извините, есди кого обидел
SQL Error [53200]: ОШИБКА: нехватка разделяемой памяти Подсказка: Возможно, следует увеличить параметр max_locks_per_transaction
При выполнении запросов на БД (Postgres) возникла ошибка:
24.02.21 13:50:38.219,main,ERROR,ExecSql,null
com.bssys.db.jdbc.DBSQLException: ОШИБКА: нехватка разделяемой памяти
Подсказка: Возможно, следует увеличить параметр max_locks_per_transaction.
Подробная информация по параметру здесь. Коротко ниже:
max_locks_per_transaction (integer)
Этот параметр управляет средним числом блокировок объектов, выделяемым для каждой транзакции; отдельные транзакции могут заблокировать и больше объектов, если все они умещаются в таблице блокировок.
Значение по умолчанию = 64
рядом также находится параметр max_pred_locks_per_transaction (integer)
В файле postgresql.conf (Postgres/data/) указано так:
#———————————————————————-
# LOCK MANAGEMENT
#———————————————————————-
#deadlock_timeout = 1s
#max_locks_per_transaction = 64 # min 10
# (change requires restart)
#max_pred_locks_per_transaction = 64 # min 10
# (change requires restart)
Изменил на это значение:
#———————————————————————-
# LOCK MANAGEMENT
#———————————————————————-
#deadlock_timeout = 1s
max_locks_per_transaction = 256 # min 10
# (change requires restart)
max_pred_locks_per_transaction = 1000 # min 10
# (change requires restart)
P.S. После изменения убрать символ «#» в начале строки
Популярные сообщения из этого блога
КБК. КВФО — Код вида финансового обеспечения (деятельности)
НПА: Приказ Минфина России от 01.12.2010 N 157н Письмо Минфина России от 18 января 2018 г. N 02-06-10/2715 В целях организации и ведения бухгалтерского учета, утверждения Рабочего плана счетов применяются следующие коды вида финансового обеспечения (деятельности): для государственных (муниципальных) учреждений, организаций, осуществляющих полномочия получателя бюджетных средств, финансовых органов соответствующих бюджетов и органов, осуществляющих их кассовое обслуживание: 1 — деятельность, осуществляемая за счет средств соответствующего бюджета бюджетной системы Российской Федерации (бюджетная деятельность); 2 — приносящая доход деятельность (собственные доходы учреждения); 3 — средства во временном распоряжении; 4 — субсидии на выполнение государственного (муниципального) задания; 5 — субсидии на иные цели; 6 — субсидии на цели осуществления капитальных вложений; 7 — средства по обязательному медицинскому страхованию; для отражения органами Федерального казн
TRUNCATE / DELETE / DROP или как очистить таблицу
ИМЕЕМ: Таблица MSG (сообщения) с большим количеством записей. SQL> CREATE TABLE msg (id INTEGER NOT NULL PRIMARY KEY, description CHAR (50) NOT NULL, date_create DATE); ЗАДАЧА: Необходимо очистить таблицу от данных РЕШЕНИЕ: Для решения данной задачи есть несколько способов. Ниже описание и пример каждого из них. Способ №1 — используем DELETE Самый простой способ (первый вариант) — выполнение оператора удаления записи. При его выполнении вы будете видеть результат (сколько записей удалено). Удобная штука когда необходимо точно знать и понимать правильные ли данные удалены. НО имеет недостатки перед другими вариантами решения поставленной задачи. SQL> DELETE FROM msg; —Удалит все строки в таблице SQL> DELETE FROM msg WHERE date_create = ‘2019.02.01’; —Удалит все строки у которых дата создания «2019.02.01» Способ №2 — используем TRUNCATE Использование оператора DML для очистки всех строк в та
Linux (РедОС). Сброс пароля
Используется ОС РедОС 7.1, которая установлена в VBox. В процессе установки ОС, был задан только пароль для «root», дополнительных пользователей не создавалось. В рекомендациях на сайте производителя ОС указано: Помимо администратора РЕД ОС (root) в систему необходимо добавить, по меньшей мере, одного обычного пользователя. Работа от имени администратора РЕД ОС считается опасной (можно по неосторожности повредить систему), поэтому повседневную работу в РЕД ОС следует выполнять от имени обычного пользователя, полномочия которого ограничены. После перезапуска и попытке войти в систему под root, система выдает сообщение «Не сработало .попробуйте еще раз». Поэтому для решения проблемы было решено создать пользователя, для этого выполняем такие действия: После загрузки, в момент выбора системы, быстро нажимаем стрелки вверх и вниз (приостанавливаем обратный отсчет). Выбираем ядро и нажимаем «e». Находим строку, которая относится к ядру: здесь будет ряд «boot parameter
ТФФ 34.0. Полный перечень документов альбома ТФФ (Таблица 2)
Для удобства и поиска информации по томам, маркерам и обозначении версии ТФФ. Таблица актуальна — версия 34.0 — (дата начала действия с 01.01.2023 г.) Ссылки на предыдущие версии форматов: ТФФ 33.0 — https://albafoxx.blogspot.com/2021/01/320-2.html ТФФ 32.0 — https://albafoxx.blogspot.com/2020/01/310-2.html ТФФ 31.0 — https://albafoxx.blogspot.com/2020/01/310-2.html ТФФ 30.0 — https://albafoxx.blogspot.com/2019/12/300-2.html ТФФ 29.0 — https://albafoxx.blogspot.com/2019/05/290-2.html ТФФ 28.0 — https://albafoxx.blogspot.com/2019/04/2.html Наименование документа (справочника) Маркер Номер версии ТФО документа № тома Казначейское уведомление SU TXSU190101 2 Расходное расписание, Реестр расходных расписаний AP TXAP190101 1 Перечень целевых субсидий TL TXTL170101 1 Уведомление (протокол), Ин
Johan
06.09.17 — 08:02
Добрый день,прошу помощи в решении проблемы
пользую 1с 8.3.9.2309 + PostgreSql 9.4.2-1.1C происходит ошибка при загрузке базы dt ,ошибка 53200 error out of memory detail failed on request of size 536870912
ОС windows server 2016 standard,аналогичная проблема и на других ос
Пробовал менять настройки конфига pg,сейчас они такие
Это из основных как я полагаю интересующих :
shared_buffers = 64MB # min 128kB
temp_buffers = 256MB # min 800kB
work_mem = 128MB # min 64kB
maintenance_work_mem = 256MB # min 1MB
effective_cache_size = 6GB
——————————————
Всего оперативной памяти 16gb
Причём конкретно только одна база не загружается (она исправна,её тестировал БП 2.0)
ещё пробовал увеличить файл подкачки на диске С
Помогите кто сталкивался с такой же проблемой?кто её решил?
Arh01
1 — 06.09.17 — 08:10
разрядность PostgreSql какая?
Johan
2 — 06.09.17 — 08:12
(1) 64 разрядная как и windows server
Johan
3 — 06.09.17 — 08:21
В логе вот что пишет:
pg_authid_rolname_index: 1024 total in 1 blocks; 552 free (0 chunks); 472 used
MdSmgr: 8192 total in 1 blocks; 6544 free (0 chunks); 1648 used
LOCALLOCK hash: 8192 total in 1 blocks; 2880 free (0 chunks); 5312 used
Timezones: 79320 total in 2 blocks; 5968 free (0 chunks); 73352 used
ErrorContext: 8192 total in 1 blocks; 8176 free (0 chunks); 16 used
2017-09-04 18:55:43 MSK ERROR: out of memory
2017-09-04 18:55:43 MSK DETAIL: Failed on request of size 536870912.
2017-09-04 18:55:43 MSK CONTEXT: COPY config, line 328, column binarydata
2017-09-04 18:55:43 MSK STATEMENT: COPY Config FROM STDIN BINARY
rphosts
4 — 06.09.17 — 08:21
попробуй в work_mem указать немного больше чем от тебя просят
Johan
5 — 06.09.17 — 08:22
ставил 256 и 512
rphosts
6 — 06.09.17 — 08:22
и да, этот ДТ куда-то вообще загружается? Он точно не битый?
rphosts
7 — 06.09.17 — 08:23
(5) переведи «on request of size 536870912»
Johan
8 — 06.09.17 — 08:25
(6) Да как файловая база он загружается
Johan
9 — 06.09.17 — 08:27
(6) и точно не битый делал тестирование и исправление и chdbfl,без ошибок
Johan
10 — 06.09.17 — 08:30
(7)размер по запросу 536870912,полагаю что не хватает памяти загрузить какую то таблицу
Johan
11 — 06.09.17 — 08:31
а где её увеличить!?или может какой то другой параметр нужно увеличить
rphosts
12 — 06.09.17 — 08:34
(11) 536 больше 512?
Johan
13 — 06.09.17 — 08:36
(12) я понял к чему ты,я пробовал и 1024 ставить
Johan
14 — 06.09.17 — 08:36
(12) но вот только не везде
Johan
15 — 06.09.17 — 08:39
Попробую work_mem выставить > 536 ,но смогу попробовать вечером
rphosts
16 — 06.09.17 — 08:52
(15) сделай сразу побольше чтобы наверняка
Johan
17 — 06.09.17 — 09:07
(16) да 1024 поставлю,отпишусь по результату
Asmody
18 — 06.09.17 — 09:20
и temp_buffers тоже.
Asmody
19 — 06.09.17 — 09:30
shared_buffers рекомендуется делать побольше. 1/4 — 1/3 RAM.
maintenance_work_mem в 1/2 RAM или больше (до RAM-shared_buffers)
Johan
20 — 06.09.17 — 09:40
(19) если не ошибаюсь то пробовал я ставить и больше 1 gb в
shared_buffers или temp_buffers служба pg перестаёт запускаться
Johan
21 — 06.09.17 — 11:01
(16) Попробывал,выставить 1024 work_mem,shared_buffers,temp_buffers ошибка всё равно выходит
Johan
22 — 06.09.17 — 11:04
Увидел вот какой момент,в свойствах Pg есть строка версии где написано PostgreSQL 9.4.2,complited by Visual C++ build 1500, 32-bit
Johan
23 — 06.09.17 — 11:06
мне эта строка не нравится,типа используются компоненты Visual C++ 32 бита,посмотрел на давно созданном сервере тоже на pg там 64 стоит м.б дело в этом!?
Johan
24 — 06.09.17 — 11:26
Похоже что да,вроде как ура..грузит ,но ошибку не выкидывает
Johan
25 — 06.09.17 — 11:36
победа,парни дико извиняюсь,3 дня не в ту сторону смотрел,не тот дистрибутив поставил поставил общий,а надо было postgresql-9.4.2-1.1C_x64
Arh01
26 — 06.09.17 — 11:49
(25) Теперь научился отличать приложения х64 от х86?
dezss
27 — 06.09.17 — 11:55
(12) они равны
Johan
28 — 06.09.17 — 12:35
(26) Да,я поставил не посмотрев,а в описании в pg и сервис написано 64 Bit,а вот когда увидел строку версии ,тогда меня смутило
DBA’s occasionally experience “out of memory” errors that can cause failed queries and degrade system performance. Fortunately, the Greenplum Database provides facilities to avoid this.
We will discuss two of those facilities: the gp_vmem_protect_limit parameter, and Greenplum resource queues. The parameters and techniques mentioned here are explained in detail in the Greenplum Database Administrator Guide.
The gp_vmem_protect_limit parameter: The “gp_vmem_protect_limit” parameter sets the amount of memory that all processes of an active segment instance can consume. Queries that cause the limit to be exceeded will be cancelled.
Note that this is a local parameter and must be set for each segment in the system. The system must be restarted for parameter changes to take effect.
How to set the gp_vmem_protect_limit
As a general rule-of-thumb, gp_vmem_protect_limit should be set to:
( X * physical_memory_in_MB ) /#_of_primary_segments
X should be a value between 1.0 and 1.5. A value of X=1.0 offers the best overall system performance; a value of X=1.5 may impact system performance because of swap activity but will result in fewer canceled queries.
For example, to set gp_vmem_protect_limit conservatively (X=1.0) on a segment host with 16GB (16384 MB) of physical memory with 4 primary segment instances, the calculation would be: (1 * 16384) / 4 = 4096.
The MEMORY_LIMIT parameter for Greenplum Resource Queues:Greenplum resource queues provide a way to manage and prioritize workloads. Resource queues can be created with a MEMORY_LIMIT setting to restrict the total amount of memory that queries can consume in any segment instance. Queries that cause a queue to exceed the MEMORY_LIMIT must wait until queue resources are free before they can execute.
By assigning each user to a queue and limiting the amount of memory queues can consume, administrators can ensure proper resource allocation across the system.
Note that roles with the SUPERUSER attribute are exempt from queue limits.
How to set MEMORY_LIMIT to avoid Out of Memory errors:As a general rule-of-thumb, the sum of all the MEMORY_LIMITs across all the queues should be no more than 90% of the gp_vmem_protect_limit.
Common Out of Memory Errors
The two most common errors are described below. They look similar but have different reasons and solutions.
Error code 53200
Example:
«ERROR»,»53200″,»Out of memory. Failed on request of size 156 bytes. (context ‘CacheMemoryContext’) (aset.c:840)»
Description:
The system canceled a query because a segment server’s OS did not have enough memory to satisfy a postmaster process allocation request.
How to Avoid
1. Set gp_vmem_protect_limit according to the formula above.
2. Adding memory can help greatly if lowering gp_vmem_protect_limit results in too many canceled queries.(Gp_vmem_protect_limit can be raised after adding memory.)
3. Adding swap space may help, although increased swap activity will impact system performance.
Error code 53400
Example
«ERROR»,»53400″,»Out of memory (seg13 slice13 sdw1-1:40001 pid=10183)»,»VM Protect failed to allocate 8388608 bytes, 6 MB available»
Description
The system canceled a query because a postmaster process tried to request more memory than the gp_vmem_protect_limit parameter allows.
How to Avoid
1. Make sure the sum of all MEMORY_LIMITs across all active queues is <= 90% of gp_vmem_protect_limit.
2. Increase gp_vmem_protect_limit, if possible, using the formula described above.
3. Ensure the system is not unbalanced (i.e., some segments down). Use gpstate -e to verify.
Thanks for contributing to pgloader by reporting an
issue! Reporting an issue is the only way we can solve problems, fix bugs,
and improve both the software and its user experience in general.
The best bug reports follow those 3 simple steps:
- My command file:
LOAD DATABASE
FROM mysql://dps:@localhost/XXXXXXX
INTO postgresql://xxxxx:xxxxx@192.168.xx.xx/XXXXXXX
WITH workers = 4, concurrency = 2;
- Results
Heap exhausted during garbage collection: 0 bytes available, 48 requested.
Gen StaPg UbSta LaSta LUbSt Boxed Unboxed LB LUB !move Alloc Waste Trig WP GCs Mem-age
0: 0 0 0 0 0 0 0 0 0 0 0 42949672 0 0 0.0000
1: 0 0 0 0 0 0 0 0 0 0 0 42949672 0 0 0.0000
2: 0 0 0 0 0 0 0 0 0 0 0 42949672 0 0 0.0000
3: 123995 123996 0 0 13084 73279 227 0 226 2817738000 19643120 1271620360 0 1 1.2103
4: 130992 131071 0 0 5735 28068 6051 0 2 1295775984 10159888 2000000 0 0 0.0000
5: 0 0 0 0 0 0 0 0 0 0 0 2000000 0 0 0.0000
6: 0 0 0 0 3437 1191 0 0 0 151650304 0 2000000 3270 0 0.0000
Total bytes allocated = 4265164288
Dynamic-space-size bytes = 4294967296
GC control variables:
*GC-INHIBIT* = true
*GC-PENDING* = true
*STOP-FOR-GC-PENDING* = false
fatal error encountered in SBCL pid 2093(tid 140737042183936):
Heap exhausted, game over.
Welcome to LDB, a low-level debugger for the Lisp runtime environment.
Additionally, further attempts to modify the schema directly with PSQL give the following error:
psql (10.6 (Ubuntu 10.6-0ubuntu0.18.04.1))
Type "help" for help.
xxxxx=# DROP SCHEMA xxxxxxxxx CASCADE;
ERROR: out of shared memory
HINT: You might need to increase max_locks_per_transaction.
Additionally, further attempts to preform the load result in the following:
2019-01-17T20:14:35.034000Z NOTICE Starting pgloader, log system is ready.
2019-01-17T20:15:22.600000Z NOTICE Prepare PostgreSQL database.
2019-01-17T20:15:22.606000Z NOTICE DROP SCHEMA xxxxxxxxxxx CASCADE;
2019-01-17T20:15:22.807000Z ERROR Database error 53200: out of shared memory
HINT: You might need to increase max_locks_per_transaction.
QUERY: DROP SCHEMA xxxxxxxxxxxx CASCADE;
2019-01-17T20:15:22.807000Z FATAL Failed to create the schema, see above.
2019-01-17T20:15:22.807000Z LOG report summary reset
table name read imported errors total time read write
----------------- --------- --------- --------- -------------- --------- ---------
fetch meta data 9908 9908 0 13.231s
Create Schemas 0 0 0 0.000s
----------------- --------- --------- --------- -------------- --------- ---------
- explain how the result is not what you expected.
I have loaded prior versions of the same schema with pgloader without error.
I would expect this schema to work the same.
In the case of pgloader, here’s the information I will need to read in your
bug report. Having all of this is a big help, and often means the bug you
reported can be fixed very efficiently as soon as I get to it.
Please provide the following information:
- pgloader —version
pgloader version «3.4.1»
compiled with SBCL 1.3.3.debian
and
pgloader version «3.5.2~devel»
compiled with SBCL 1.4.14
Both have the same issue
- did you test a fresh compile from the source tree?
Yes - did you search for other similar issues?
Yes - how can I reproduce the bug?
The data is propriety