I’m building a website which will be used to handle excel files from stores and manipulate them (merging, view, etc.). I’m using PostgreSQL 9.4 for the database, running on Centos 6.6 VM with 4GB RAM. It has 3 databases as follow:
- postgres database
- db_raw, which is used as a placeholder for the data. The excel which are uploaded from the website will be parsed, and the data will be stored here. The database consists of few tables used to keep the data required to process the excel, and a huge table for storing the excel data with currently >140 column and almost 1 million row
- db_processed, which is the main database for the website. It has few small tables for the operational of the website (user table, access list, logging, etc), and 8 tables to store the processed excel data from db_raw. Each of the 8 tables have around 40 column and about a million row.
The databases were running fine until this morning. I tried connecting to the db_processed through pgAdmin and PuTTY, and PostgreSQL gave me this message
FATAL: invalid memory alloc request size 144115188075856068
db_raw works fine, and nothing has been changed since 3 days ago as far as I know. What should I do so I can connect to the database again?
update : I did what @CraigRinger said and restarted the service. I manage to connect to the database, but all the tables are gone 
now this keeps appearing in the log
< 2015-09-21 12:27:22.155 WIB >DEBUG: performing replication slot checkpoint
< 2015-09-21 12:27:22.158 WIB >LOG: request to flush past end of generated WAL; request 46/9E0981D8, currpos 46/771C69B0
< 2015-09-21 12:27:22.158 WIB >CONTEXT: writing block 2 of relation base/18774/12766
< 2015-09-21 12:27:22.158 WIB >ERROR: xlog flush request 46/9E0981D8 is not satisfied --- flushed only to 46/771C69B0
< 2015-09-21 12:27:22.158 WIB >CONTEXT: writing block 2 of relation base/18774/12766
< 2015-09-21 12:27:22.158 WIB >WARNING: could not write block 2 of base/18774/12766
< 2015-09-21 12:27:22.158 WIB >DETAIL: Multiple failures --- write error might be permanent.
asked Sep 21, 2015 at 4:52
2
It is caused by corrupted rows.
Create a function do «detect» the rows that are corrupted:
CREATE OR REPLACE FUNCTION is_bad_row(tableName TEXT, tabName TEXT, tidInitial tid)
RETURNS integer
as $find_bad_row$
BEGIN
EXECUTE 'SELECT (each(hstore(' || tabName || '))).* FROM ' || tableName || ' WHERE ctid = $1' USING tidInitial;
RETURN 0;
EXCEPTION
WHEN OTHERS THEN
RAISE NOTICE '% = %: %', tidInitial, SQLSTATE, SQLERRM;
RETURN 1;
END
$find_bad_row$
LANGUAGE plpgsql;
… and then create a «temp table» to store the ctid of the bad rows:
create table bad_rows as
SELECT ctid as row_tid
FROM your_schema.your_table
where is_bad_row('your_schema.your_table', 'your_table', ctid) = 1
… and after that you just need to delete those rows:
delete from your_schema.your_table where ctid in (select row_tid from bad_rows)
… and remove the «temp table»:
drop table bad_rows
answered May 28, 2020 at 17:57
ChristianChristian
6,9449 gold badges51 silver badges79 bronze badges
2
Содержание
- «invalid memory alloc request size» from PostgreSQL with large query results #4918
- Comments
- Issue Summary
- Steps to Reproduce
- Technical details:
- Footer
- «invalid memory alloc request size» from PostgreSQL with large query results #4918
- Comments
- Issue Summary
- Steps to Reproduce
- Technical details:
- Footer
- MS Sql -> Postgres
- MS Sql -> Postgres
- Thread: standby replication server throws invalid memory alloc request size ,does not start up
- standby replication server throws invalid memory alloc request size ,does not start up
«invalid memory alloc request size» from PostgreSQL with large query results #4918
Issue Summary
I’m not sure if it’s directly related to #78, so I start a new issue.
When a query returns too much data, we get an explicit PostgreSQL error when Redash tries to insert the query result into its query_results table.
Steps to Reproduce
- Run a query returning a lot of data (5379488 rows and 260MB of data in our case)
Few seconds later, PostgreSQL returns in its log:
1 minute), the UI reports «Error running query: failed communicating with server. Please check your Internet connection and try again.»
Note that is not only about the number of rows returned, querying only one column over all the rows works.
I didn’t find any PostgreSQL settings to tweak to get through this error. After some investigations, the error comes from palloc functions: https://doxygen.postgresql.org/palloc_8h.html#a7d104f43412595fb2d3ca12963084f23
What I still didn’t understand is why Redash/PostgreSQL requires more than 1GB memory to insert only 260MB of query result.
Technical details:
- Redash Version: redash/redash:8.0.0.b32245
- How did you install Redash: Docker/docker-compose, following the official procedure.
The text was updated successfully, but these errors were encountered:
What I still didn’t understand is why Redash/PostgreSQL requires more than 1GB memory to insert only 260MB of query result.
How did you measure the size of the dataset? Anyway, the difference can be because of the serialization used (JSON, each row is an object).
Also, I’m not sure this error is about exceeding 1gb, but more about just not having enough memory to allocate.
Note that is not only about the number of rows returned, querying only one column over all the rows works.
Of course, it’s about the total size of the dataset.
Beside the general need to support better large data sets, the issue described here is more about your system configuration than anything in the code.
How did you measure the size of the dataset? Anyway, the difference can be because of the serialization used (JSON, each row is an object).
I just dumped the table and got the file size. Of course it’s more to get a rough idea of how big the dataset is, not an accurate value.
Also, I’m not sure this error is about exceeding 1gb, but more about just not having enough memory to allocate.
That’s what I thought first as I ran through this error, but Redash runs on a public cloud instance with a comfortable 14GB total memory, on Debian buster without memory or other resources limits.
So, I managed to capture the whole query sent to PostgreSQL. The INSERT is 606MB big. I then tried to replay the INSERT on multiple environments: PostgreSQL 9.6 or 11, alpine/standard image, docker or bare-metal, on other servers. The query fails in all scenarios with the same error. I think we hit a limit somewhere in PostgreSQL.
I close the issue since it’s only a consequence of #78
© 2023 GitHub, Inc.
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Источник
«invalid memory alloc request size» from PostgreSQL with large query results #4918
Issue Summary
I’m not sure if it’s directly related to #78, so I start a new issue.
When a query returns too much data, we get an explicit PostgreSQL error when Redash tries to insert the query result into its query_results table.
Steps to Reproduce
- Run a query returning a lot of data (5379488 rows and 260MB of data in our case)
Few seconds later, PostgreSQL returns in its log:
1 minute), the UI reports «Error running query: failed communicating with server. Please check your Internet connection and try again.»
Note that is not only about the number of rows returned, querying only one column over all the rows works.
I didn’t find any PostgreSQL settings to tweak to get through this error. After some investigations, the error comes from palloc functions: https://doxygen.postgresql.org/palloc_8h.html#a7d104f43412595fb2d3ca12963084f23
What I still didn’t understand is why Redash/PostgreSQL requires more than 1GB memory to insert only 260MB of query result.
Technical details:
- Redash Version: redash/redash:8.0.0.b32245
- How did you install Redash: Docker/docker-compose, following the official procedure.
The text was updated successfully, but these errors were encountered:
What I still didn’t understand is why Redash/PostgreSQL requires more than 1GB memory to insert only 260MB of query result.
How did you measure the size of the dataset? Anyway, the difference can be because of the serialization used (JSON, each row is an object).
Also, I’m not sure this error is about exceeding 1gb, but more about just not having enough memory to allocate.
Note that is not only about the number of rows returned, querying only one column over all the rows works.
Of course, it’s about the total size of the dataset.
Beside the general need to support better large data sets, the issue described here is more about your system configuration than anything in the code.
How did you measure the size of the dataset? Anyway, the difference can be because of the serialization used (JSON, each row is an object).
I just dumped the table and got the file size. Of course it’s more to get a rough idea of how big the dataset is, not an accurate value.
Also, I’m not sure this error is about exceeding 1gb, but more about just not having enough memory to allocate.
That’s what I thought first as I ran through this error, but Redash runs on a public cloud instance with a comfortable 14GB total memory, on Debian buster without memory or other resources limits.
So, I managed to capture the whole query sent to PostgreSQL. The INSERT is 606MB big. I then tried to replay the INSERT on multiple environments: PostgreSQL 9.6 or 11, alpine/standard image, docker or bare-metal, on other servers. The query fails in all scenarios with the same error. I think we hit a limit somewhere in PostgreSQL.
I close the issue since it’s only a consequence of #78
© 2023 GitHub, Inc.
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Источник
MS Sql -> Postgres
Есть 2 базы. БУХ 3.0 и УПП 1.3
Перенос проводил через выгрузку загрузку .DT с предварительным ТИИ .
Бух 3.0 нормально перенеслась из MS SQL в Postgres . Бэкапится и работает.
УПП 1.3: При проведении документа ОШИБКА СУБД cache lookup failed for function 0
Поиски привели к необходимости сделать Дамп/Бэкап
При попытке сделать Бэкап, ошибка:
pg_dump: saving standard_conforming_strings = off
pg_dump: saving search_path =
pg_dump: saving database definition
pg_dump: [archiver (db)] query failed: ERROR: invalid memory alloc request size 1191164729
pg_dump: [archiver (db)] query was: FETCH 100 FROM _pg_dump_cursor
(1)
Доброго дня.
Аналогично пытался перенести упп на postgres. База около 30 гиг размером.
PG с сайта 1с последний. Предприятие оттуда же, 8.3.15.
Получил такую же ошибку.
Дамп делал, не помогло.
Так же пробовал делать тестирование и исправление. Все проходит успешно, если не ставить галку «реструктуризация таблиц». На этом падает.
Но эффект от этих действий нулевой.
Пришлось вернуться к mssql.
Осталось попробовать только pg_dumpall.
Тоже перенес на Postgres
8.3.16.1148 конфиг бухгалтерия 1.2
база маленькая, места навалом, проверка и рестурктуризация на ура
А вот отмена проведения произвольного документа (не всех) вываливает эту ошибку
Нагуглил что это связано с шаманствами преобразования строк mvarchar — но как исправить не нашел
Бухгалтерия 2.0
Очередное обновление потребовало обновление платформы. Заодно, решили обновить PostgreSQL.
И так, платформа 8.3.16.1148 и PostgreSQL 11.5-12
В итоге, на многих операциях (проведение документа, пометка на удаление и тп) — ОШИБКА СУБД cache lookup failed for function 0
Пришлось понизить версию PostgreSQL до 10.10-4
Поимел такую же ошибку (ОШИБКА СУБД cache lookup failed for function 0) на УПП 1.3, релиз 1.3.134.1, платформа 8.3.15.1489, постгрес 11.5-12.1С(х64).
База небольшая, dt 1.3гб. *.dt выгружается, на файловой базе ошибки нет. Конфигурация почти типовая, но без замочка.
Использовал различные танцы с бубном навроде: майнтенанс базы pgAdmin-ом, ТИИ, вкуривание логов постгре, изменение регистра бухгалтерии туда-сюда (для инициирования реструктуризации и пересоздания таблиц в постгре), удаления проблемной таблицы средствами постгре. Логи постгре говорят, что проблема в таблице итогов регистра бухгалтерии по субконто _AccRgAT21653. Но что с этой таблицей ни делай, ошибка возвращается.
РЕШЕНИЕ:
поставил в конфигурации режим совместимости «Версия 8.3.9». Да, появляются артефакты, вроде дублирования имен картинок (которые в 8.3.9 стали системными) и некоторых функций общего модуля ОбщийМодуль.ИнтеграцияЕГАИСУТКлиентСерверГлобальный.Модуль(8,9)>: Процедура или функция с указанным именем уже определена (СтрНайти) — нужно переименовывать функции.
Но проблема с cache lookup failed ушла. Прогонял разные документы — пока все ровно. Буду наблюдать далее.
BTW: УПП в дефолтовом режиме совместимости весьма плохо дружит с постгре в плане производительности. на большой базе с количеством пользователей около 100 было невозможно работать, пока не поднял режим совместимости. После этого платформа 1с начинает генерировать адекватные запросы в постгре.
Источник
MS Sql -> Postgres
Есть 2 базы. БУХ 3.0 и УПП 1.3
Перенос проводил через выгрузку загрузку .DT с предварительным ТИИ .
Бух 3.0 нормально перенеслась из MS SQL в Postgres . Бэкапится и работает.
УПП 1.3: При проведении документа ОШИБКА СУБД cache lookup failed for function 0
Поиски привели к необходимости сделать Дамп/Бэкап
При попытке сделать Бэкап, ошибка:
pg_dump: saving standard_conforming_strings = off
pg_dump: saving search_path =
pg_dump: saving database definition
pg_dump: [archiver (db)] query failed: ERROR: invalid memory alloc request size 1191164729
pg_dump: [archiver (db)] query was: FETCH 100 FROM _pg_dump_cursor
(1)
Доброго дня.
Аналогично пытался перенести упп на postgres. База около 30 гиг размером.
PG с сайта 1с последний. Предприятие оттуда же, 8.3.15.
Получил такую же ошибку.
Дамп делал, не помогло.
Так же пробовал делать тестирование и исправление. Все проходит успешно, если не ставить галку «реструктуризация таблиц». На этом падает.
Но эффект от этих действий нулевой.
Пришлось вернуться к mssql.
Осталось попробовать только pg_dumpall.
Тоже перенес на Postgres
8.3.16.1148 конфиг бухгалтерия 1.2
база маленькая, места навалом, проверка и рестурктуризация на ура
А вот отмена проведения произвольного документа (не всех) вываливает эту ошибку
Нагуглил что это связано с шаманствами преобразования строк mvarchar — но как исправить не нашел
Бухгалтерия 2.0
Очередное обновление потребовало обновление платформы. Заодно, решили обновить PostgreSQL.
И так, платформа 8.3.16.1148 и PostgreSQL 11.5-12
В итоге, на многих операциях (проведение документа, пометка на удаление и тп) — ОШИБКА СУБД cache lookup failed for function 0
Пришлось понизить версию PostgreSQL до 10.10-4
Поимел такую же ошибку (ОШИБКА СУБД cache lookup failed for function 0) на УПП 1.3, релиз 1.3.134.1, платформа 8.3.15.1489, постгрес 11.5-12.1С(х64).
База небольшая, dt 1.3гб. *.dt выгружается, на файловой базе ошибки нет. Конфигурация почти типовая, но без замочка.
Использовал различные танцы с бубном навроде: майнтенанс базы pgAdmin-ом, ТИИ, вкуривание логов постгре, изменение регистра бухгалтерии туда-сюда (для инициирования реструктуризации и пересоздания таблиц в постгре), удаления проблемной таблицы средствами постгре. Логи постгре говорят, что проблема в таблице итогов регистра бухгалтерии по субконто _AccRgAT21653. Но что с этой таблицей ни делай, ошибка возвращается.
РЕШЕНИЕ:
поставил в конфигурации режим совместимости «Версия 8.3.9». Да, появляются артефакты, вроде дублирования имен картинок (которые в 8.3.9 стали системными) и некоторых функций общего модуля ОбщийМодуль.ИнтеграцияЕГАИСУТКлиентСерверГлобальный.Модуль(8,9)>: Процедура или функция с указанным именем уже определена (СтрНайти) — нужно переименовывать функции.
Но проблема с cache lookup failed ушла. Прогонял разные документы — пока все ровно. Буду наблюдать далее.
BTW: УПП в дефолтовом режиме совместимости весьма плохо дружит с постгре в плане производительности. на большой базе с количеством пользователей около 100 было невозможно работать, пока не поднял режим совместимости. После этого платформа 1с начинает генерировать адекватные запросы в постгре.
Источник
Thread: standby replication server throws invalid memory alloc request size ,does not start up
standby replication server throws invalid memory alloc request size ,does not start up
This is my first postgres query to admin list, so if I am not following the right standards for asking the question, pls let me know рџЉ
I have a postgres cluster as
A (primary)-> streaming replication -> B(hot_standby=on)
We had a power outage in one of the data centers, and when we got back, one of the databases servers (B the standby node) seem to show weird errors and is not starting up. A recovered fine, and it running fine.
2018-06-25 10:57:04 UTC HINT:В In a moment you should be able to reconnect to the database and repeat your command.
2018-06-25 10:57:04 UTC WARNING:В terminating connection because of crash of another server process
2018-06-25 10:57:04 UTC 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.
2018-06-25 10:57:04 UTC HINT:В In a moment you should be able to reconnect to the database and repeat your command.
2018-06-25 10:57:04 UTC LOG:В database system is shut down
2018-06-27 16:59:28 UTC LOG:В listening on IPv4 address «0.0.0.0», port 5432
2018-06-27 16:59:28 UTC LOG:В listening on IPv6 address «::», port 5432
2018-06-27 16:59:28 UTC LOG:В listening on Unix socket «/var/run/postgresql/.s.PGSQL.5432»
2018-06-27 16:59:28 UTC LOG:В database system was interrupted while in recovery at log time 2018-06-25 10:52:21 UTC
2018-06-27 16:59:28 UTC HINT:В If this has occurred more than once some data might be corrupted and you might need to choose an earlier recovery target.
2018-06-27 16:59:28 UTC LOG:В entering standby mode
2018-06-27 16:59:28 UTC LOG:В recovered replication state of node 1 to 63/89B52A98
2018-06-27 16:59:28 UTC LOG:В redo starts at 9A/6F1B3888
2018-06-27 16:59:28 UTC LOG:В consistent recovery state reached at 9A/6F25BFF0
2018-06-27 16:59:28 UTC FATAL:В invalid memory alloc request size 1768185856
2018-06-27 16:59:28 UTC LOG:В database system is ready to accept read only connections
2018-06-27 16:59:28 UTC LOG:В startup process (PID 11829) exited with exit code 1
2018-06-27 16:59:28 UTC LOG:В terminating any other active server processes
2018-06-27 16:59:28 UTC LOG:В database system is shut down
pg_ctl: could not start server
Examine the log output.
I did a lot of searching around “invalid memory alloc request” it mostly points to some data error,
mem checks and disks are ok.
I tookВ a filesystem snapshot, synced it onto another server and tried to reload it, it gave the same error.
Now to ensure there was not real data causing this issue, I took a full dump of the primary db (A) using pg_dumpall and restored in onto the test server. I was able to load the db and was able to query the tables without issues.
So I am confused why the standby is behaving weird after the power outage.
Just FYI, I spun up a new node ( В CВ ) as a replacement for the problem standby(B) with pg_baseback and it is working fine. Can query all tables without problems. My only concern was do I need to worry about this error showing up again?
Most the googling points to some operation and finding out errors in some operation performed etc,
I ran that function (in 1), could not find bad data rows.
Also, I tried to bump up (memory to 32GB, cpu to 8 cpu and shmmax to В 18446744073692774399 to figure out is there was any resource constraint that I could temp bump up and then debug what went wrong, but it did not start up.
postgres (PostgreSQL) 10.4 (Ubuntu 10.4-2.pgdg16.04+1)
Источник
After 3 days of running an import routine written on RoR to move some 269,000 records from a legacy database via csv files the routine finally finished.
The very first thing I attempt to do is to backup the database using pg_dump before doing anything else.
This resulted in the following
pg_dump -Ft hsb > hsb_after_full_import.tar
pg_dump: Dumping the contents of table "companies" failed: PQgetResult() failed.
pg_dump: Error message from server: ERROR: invalid memory alloc request size 18446744073709551613
pg_dump: The command was: COPY public.companies (id, category_id, city_id, name, address, town, neighbourhood, post_code, lon, lat, contact, email, facebook, twitter, listing_url, image_url, phone, website, listing_cid, promotion, description, rating, reviews, wheelchair_accessible, merchant_verified, uploaded, created_at, updated_at, server_id, opening_hours, multinational, places_id, featured_image_file_name, featured_image_content_type, featured_image_file_size, featured_image_updated_at, places_lat, places_lon, source, sanitised) TO stdout;
I am unable to find a tool to verify and fix any potential corruption. Indeed I have encountered many suggestions that Postgresql doesn’t get corrupted (I find that impossible to believe) and therefore needs no repair/verification tools.
The import went smoothly and many tests of a few thousand records were undertaken before the full run to determine the suitability of the import script.
There is no point re-creating the database and re-importing if Postgresql is unable to handle this amount of data and just corrupt again.
I would really appreciate some guidance in the best way to proceed? Maybe an alternative backup tool?
The data appears to be OK. The app that is using the data seems to behave itself properly, maybe it’s just the pure size of the dump and maybe an issue with the amount of ram (4gb) I have on my machine?
PostgreSQL version
pg_config --version
PostgreSQL 9.3.12
The database was created using Rails db rake task
rake db:create
From PGAdmin III the create script looks like this
-- Table: companies
-- DROP TABLE companies;
CREATE TABLE companies
(
id serial NOT NULL,
category_id integer,
city_id integer,
name character varying(255),
address character varying(255),
town character varying(255),
neighbourhood character varying(255),
post_code character varying(255),
lon character varying(255),
lat character varying(255),
contact character varying(255),
email character varying(255),
facebook text,
twitter text,
listing_url character varying(255),
image_url character varying(255),
phone character varying(255),
website text,
listing_cid character varying(255),
promotion text,
description text,
rating character varying(255),
reviews integer,
wheelchair_accessible boolean NOT NULL DEFAULT true,
merchant_verified boolean NOT NULL DEFAULT true,
uploaded boolean NOT NULL DEFAULT true,
created_at timestamp without time zone NOT NULL,
updated_at timestamp without time zone NOT NULL,
server_id integer,
opening_hours text,
multinational boolean DEFAULT false,
places_id character varying(255),
featured_image_file_name character varying(255),
featured_image_content_type character varying(255),
featured_image_file_size integer,
featured_image_updated_at timestamp without time zone,
places_lat double precision,
places_lon double precision,
source character varying(255),
sanitised boolean DEFAULT false,
CONSTRAINT companies_pkey PRIMARY KEY (id)
)
WITH (
OIDS=FALSE
);
ALTER TABLE companies
OWNER TO wpsmiler;
I’m running Linux mint 17.3
select pg_total_relation_size(‘companies’) gives me 113459200
If I run the query manually I get some records output (I assume 100 because of the message) then the same error
Query returned more than 100 copy rows, discarding the rest...
ERROR: invalid memory alloc request size 18446744073709551613
********** Error **********
ERROR: invalid memory alloc request size 18446744073709551613
SQL state: XX000
16.10.18 — 08:52
Исходные данные :
КА 1.1.107.4 с мелкими доработками
Платформа 8.3.9.2170
СУБД Postgres Pro 9.4
Все работало стабильно почти 2 года, пока не обновил конфу на релиз 1.1.107.4 .
Заметил, что перестали восстанавливаться архивы созданные с помощью pg_dump.
Начал разбираться и выяснил, что pg_dump в процессе архивации выдает ошибки :
pg_dump: Ошибка выгрузки таблицы «config»: сбой в PQgetResult().
pg_dump: Сообщение об ошибке с сервера: Р?РЁР?Р’Р?Р?: invalid memory alloc request size 1174829507
pg_dump: Выполнялась команда: COPY public.config (filename, creation, modified,attributes, datasize, binarydata) TO stdout;
Переносил базу на другие сервера , менял версии Postgres (9.6 и 10.5), менял платформу (8.3.9.2309 и 8.3.10.2772) — результат тот же, pg_dump не может нормально создать архив.
При постановке конфы обратно на поддержку архивация начинает работать нормально.
Как можно решить проблему?
1 — 16.10.18 — 08:54
Поставить нормальный скуль не предлагать?
2 — 16.10.18 — 08:54
(0)[Как можно решить проблему?]
invalid memory alloc request size 1174829507
видимо копать нужно от сюда
3 — 16.10.18 — 08:54
в данном контексте вот эту фразу раскрой, если не трудно
// При постановке конфы обратно на поддержку //
4 — 16.10.18 — 08:55
(3) на замок
5 — 16.10.18 — 08:56
(4) когда конфа на замке, то требуется грубо в два раза меньше оперативы
6 — 16.10.18 — 08:57
Проводил эксперимент:
1. Выгружаю конфу поставщика в cf.
2. Из цф создаю чистую базу.
3. Запускаю pg_dump — архивация проходит нормально.
4. В этой же конфе включаю возможность изменения.
5. Запускаю pg_dump — архивация проходит НЕ нормально.
7 — 16.10.18 — 08:58
(5) Оперативы достаточно. Пробовал компы с 16 и 32 Гб оперативки.
Postgres Pro — х64.
8 — 16.10.18 — 09:00
+(6) только цифры после invalid memory alloc request size другие.
9 — 16.10.18 — 09:01
(7) Был у меня клиент пару лет назад. Жаловался на похожие траблы. Поскольку ему нужно было хоть какое-то решение, то ему пришлось делать все такие штуки непосредственно в линуксе — под виндой уже не работало.
Именно с конфигой на КА 1.1 !!!
10 — 16.10.18 — 09:05
Если кто имеет возможность провести эксперимент (6), попробуйте и напишите о результате. На все про все нужно 15 минут на нормальном компе.
Я пробовал на WinServer 2008 R2 и Win7 .
11 — 16.10.18 — 09:09
(2) Вроде как у Postgres лимиты не маленькие :
Максимальный размер таблицы — 32 TB
Максимальный размер строки — 400 Gb
Максимальный размер поля — 1 GB
12 — 18.10.18 — 06:42
(0)
Покажи скрипт, как бэкап делается.
[проблемы с архивацией]
не путаешь понятия дампа и архива? Проблемы именно с архивацией?
13 — 18.10.18 — 07:50
set fTime=%time%
set fHour=%fTime:~0,2%
set fHour=%fHour: =0%
set fMin=%fTime:~3,2%
Set f_date=%date%
set f_year=%f_date:~6,4%
set f_month=%f_date:~3,2%
set f_day=%f_date:~0,2%
set f_name=%f_year%_%f_month%_%f_day%_%fHour%_%fMin%
«C:Program FilesPostgresPro 1C9.4binpg_dump» -U postgres -F c -Z9 -c -f C:arcarc_pgara_backup.backup bs
ren C:arcarc_pgara_backup.backup bs_%f_name%.*
14 — 18.10.18 — 08:15
попробуй формат старндартный
убери «-F c -Z9»
15 — 18.10.18 — 08:25
(14) Не помогло. Та же ошибка.
16 — 18.10.18 — 08:39
17 — 18.10.18 — 08:43
18 — 18.10.18 — 09:36
(15) Снятие с поддержки любой другой конфигурации также приводит к такой ошибке? Или только КА указанной версии?
19 — 18.10.18 — 09:42
(18) немного не так — если снять с поддержки совсем, то есть без сохранения поддержки, то ошибка может исчезнуть.
з.ы. Трабл именно при снятии с «замка» и при сохранении поддержки
20 — 18.10.18 — 09:58
(18) Именно в версиях КА 1.1.107.3 и 1.1.107.4.
В КА 1.1.106 проблемы еще нет.
Попробовал уже с типовыми демоконфами КА — все так же.
Т.е проблема не в моей базе , а в конфигурации конкретной версии.
21 — 18.10.18 — 09:59
(19) Я понимаю. У нас бухгалтерия и зарплата в таком режиме поддержки уже много лет, ничего подобного никогда не возникало. Правда, и сервер приложений и СУБД на Linux(тоже много лет).
22 — 18.10.18 — 10:03
+(20) Тут же УТ11.4 и БП3 живут без проблем.
23 — 18.10.18 — 10:13
(19) [если снять с поддержки совсем, то есть без сохранения поддержки, то ошибка может исчезнуть]
попробую
24 — 18.10.18 — 10:26
(22) а ты выгрузи Cf и посмотри его размер, скорее всего он будет больше 1.2 Гбайт
а потом сравни с 1.1.106.1 — там будет 650 Мбайт
ларчик то просто открывается
25 — 18.10.18 — 10:55
(24) Посмотрю.
[ скорее всего он будет больше 1.2 Гбайт ]
А что за ограничение в этом случае срабатывает?
26 — 18.10.18 — 11:00
(25) Я с Postgres не работаю, а размер cf заметил в УПП 1.3.112.4 (крайний релиз)
так что дальнейшие действия у тебя на форумах Postgres
27 — 18.10.18 — 11:04
(25) твой же пост:
-*-
Вроде как у Postgres лимиты не маленькие :
Максимальный размер таблицы — 32 TB
Максимальный размер строки — 400 Gb
Максимальный размер поля — 1 GB
28 — 18.10.18 — 11:08
(27) Хочешь сказать, что платформа конфу заталкивает в 1 поле?
29 — 18.10.18 — 11:14
(28) да, это один BLOB
30 — 18.10.18 — 11:25
Вот это поворот -_-
31 — 18.10.18 — 11:38
+(25) размер cf 1.03 гб
32 — 18.10.18 — 11:42
(31) я бы чисто ради интереса грохнул что-нибудь из конфы, чтоб привести размер cf к 0.99Гб, и проверить еще раз бэкап. (что там есть такого, макеты с двоичными данными, какие-нибудь)
33 — 18.10.18 — 11:48
(32) да я ж и предлагаю — снять с поддержки полностью и размер в два раза упадет и проблема должна уйти, если это в ней причина.
34 — 18.10.18 — 11:51
(33) а тут выяснили почему работает твое кривоватое решение, лучше же нормально сделать
35 — 18.10.18 — 11:57
(34) кому? Поставщикам конфиги из 1С ?
36 — 18.10.18 — 11:57
(35) почему нет
37 — 18.10.18 — 11:59
(36) 1С предлагает всем бесплатный апгрейд с конфиги КА 1.1 на конфиг КА 2.х
38 — 18.10.18 — 12:17
(37) гильотина лучшее средство от перхоти (с)
39 — 18.10.18 — 12:57
(37) а КА 2.х не >1Гб cf?
40 — 18.10.18 — 13:14
(39) если на замке, то 615 мб в релизе 2.4.5.24
если с вклеченными изменениями с сохранением поддержки = 1.1 гиг (до внесения каких-то изменений)
Но это ни одного там в ней изменения нет, когда вкл изм и накидать туда макетов огромных, то будет больше, конечно.
з.ы. Все-таки я думаю, что в КА 1.1 там не прямая зависимость с размером, а с самим наличием «второй копии» конфигурации, которая конфликтует с «первой» при запихивании ее в БЛОБ платформой — просто глючит в данном случае при попытке архивации баз, а так оно и в других событиях глючит тоже. При накатывании обновлений из Поддержка-Обновить конфигурацию, например.
41 — 18.10.18 — 13:24
(40) [ просто глючит в данном случае при попытке архивации баз]
+100500
проблема Postgres, с MS SQL её нет
42 — 18.10.18 — 16:38
(40) Такая же проблема должна быть и под линуксом. Ведь лимит на размер поля у Postgres одинаковый для обоих версий.
43 — 18.10.18 — 16:45
(42) [pg_dump: Ошибка выгрузки таблицы «config»: сбой в PQgetResult().
pg_dump: Сообщение об ошибке с сервера: Р?РЁР?Р’Р?Р?: invalid memory alloc request size 1174829507]
таблицы «config invalid memory alloc request size 1174829507
можно и дальше позаниматься флюдом, но тема закрыта
44 — 18.10.18 — 20:19
(43) на родственном ресурсе та же ошибка в отраслевой на базе УПП 1.3.112.4 =)
http://www.sql.ru/forum/1304093/1s-molokozavod-1-3-112-4-ne-rabotaet-bekap-sredstvami-postgresql
т.е. дело однозначно в размере cf
45 — 18.10.18 — 21:19
(44) благодарю
46 — 18.10.18 — 22:55
http://www.sql.ru/forum/1302916/problema-pri-sozdanii-rezervnoy-kopii-pg-dump — каких-то конкретных положительных решений тоже не наблюдается.
Остается писать в 1С, пусть разбираются. Попутно можно было бы попробовать в Linux. Так, на всякий случай, чтобы убедиться, что там то же самое(или нет).
47 — 18.10.18 — 23:53
BLOB побился явно. Перезагрузить конфу прямой загрузкой.
>>Платформа 8.3.9.2170
Ретроград?
48 — 19.10.18 — 08:25
(47) попробовать можно, но в тех вариантах не помогало, на которые я ссылался, что ошибки с КА 1.1 возникали в серверном режиме.
49 — 19.10.18 — 08:29
я сегодня проверю вариант с большой конфигой по размеру (ка_2.4) на субд постгри и сервером на винде — сглючит или нет — проверю. Не знаю только получится ли протестить, если сервер для субд будет линуксовый… долго такое городить и профита не будет чисто поэкспериментировать и прокачать экспу разве что 
50 — 19.10.18 — 08:36
100 гигов, полёт нормальный.
SET PGPASSWORD=12344321
«C:Program FilesPostgreSQL10.3-2.1Cbinpg_dump.exe» —host localhost —port 5432 —username «postgres» —role «postgres» —no-password —format custom —blobs —section pre-data —section data —section post-data —encoding UTF8 —verbose —file «D:1cBackupNewBUH_%date:~6,4%-%date:~3,2%-%date:~0,2%.backup» «BUH»
51 — 19.10.18 — 08:39
(50) а размер выгруженной одной только CF из этой базы какой?
52 — 19.10.18 — 08:40
(50) BUH ? — это же вероятно конфигурация БП какая-то?
53 — 19.10.18 — 08:40
(51) не проверял размер CF, БП30
54 — 19.10.18 — 08:42
(53) ну дык… с этими конфигами проблем нет, не было и не будет — про такие никто и не говорит.
55 — 19.10.18 — 08:58
(54) +100500
56 — 22.10.18 — 09:17
Вырезал из конфигурации несколько макетов ненужных драйверов.
cf сократил до 0,98 Гб. Но проблема с архивацией осталась.
57 — 22.10.18 — 09:28
(56) полностью снятие с поддержки (чтоб конфа была 600мб) тоже не помогает?
58 — 22.10.18 — 09:34
(56) а какую теперь ошибку пишет?
59 — 22.10.18 — 09:37
(58) Ту же самую.
60 — 22.10.18 — 09:39
(57) Этот вариант на крайний случай. Боюсь проблем с обновлениями.
61 — 22.10.18 — 09:39
(59) ??? invalid memory alloc request size 1174829507
62 — 22.10.18 — 09:43
(61) Да. Только циферки немного другие , поскольку на демобазе эксперименты ставлю.
63 — 22.10.18 — 09:58
просто для теста пг_дамп с
—exclude-table-data=public.config
пройдет?
64 — 22.10.18 — 10:08
(63) так архивация проходит без ошибок.
65 — 22.10.18 — 10:20
(64) гугл упорно говорит, что таблица битая. Я бы уменьшил ее еще, но значительно — до 500мб, например, и еще раз пг_дамп. Это подтвердит битая или нет
66 — 22.10.18 — 11:06
можно предположить, что источником ошибки и вовсе окажется некий конкретный объект метаданных, только сколько раз надо провернуть все-все-все манипуляции, чтоб найти такой объект. Причем, сбоить этот объект начинает в процессе клонирования конфиги поставщика в подкопию основной ЦФ-конфиги
67 — 22.10.18 — 11:08
постгре под виндой чтоли?
68 — 22.10.18 — 11:12
(65) Ставлю конфу на замок , или снимаю ее с поддержки — проблема уходит.
69 — 22.10.18 — 11:14
(67) см (24)-(31) — судя по всему такая же проблема возможна и под linux.
70 — 22.10.18 — 11:21
(69) тогда бы гугл знал о ней, 1гб сейчас не то чтобы много
71 — 22.10.18 — 11:25
(70) уже знает — в (44) (46) есть ссылки.
72 — 22.10.18 — 11:28
(71) извини, но это ссылки практически такого уровня, как на ветки на нашей же мисте
73 — 22.10.18 — 11:32
(71) вероятно они твои)
https://pgconf.ru/media/2018/02/14/DBeaver_PgConf-Russia-2018.pdf
будешь дальше копать или альтернативу искать?
74 — 22.10.18 — 16:53
(66) Похоже ты прав.
Развернул демоконфу КА2, включил возможность изменения — в результате cf размером 1,2 Гб.
Архивация проходит без проблем.
75 — 24.10.18 — 10:41
Такая же проблема. dt делается. в копию серверную(Postgres pro 9.6) не грузится, ругается на память, а в файловую загрузился. Пытаюсь определить проблемный объект в метаданных. Попутно попробую в mssql 2008 загрузить dt.
76 — 24.10.18 — 11:19
(75) А я бы просто оставил базу с полностью снятой с поддержки, а обновления заготавливал по мере необходимости из файлового режима. Какая разница, если развернута тестовая копия и завершить процедуру обновления все равно нужно только на тестовой, а затем уже из тестовой забирать CF и обновлять продакшн базу сравнением/объединением.
77 — 24.10.18 — 11:37
(76) как сейчас решение да, но причина явно не устранена. попробую 107.5 накатить на файле и перенести на серверную.
78 — 24.10.18 — 14:03
В MsSQL действительно все загружается без ошибок. Проблема на стороне Postgres, попробую покопать настройки. Ни у кого нет опыта тонкой настройки? Не хочется верить, что Postgres настолько не продуман.
79 — 24.10.18 — 14:20
в релиз КА 1.1.107.5 этот косяк не убрали.
80 — 24.10.18 — 15:17
(78) никто и не заставляет. Только две конфиги КА 1.1 и УПП 1.3 — с остальными проблем нет. с КА 2.4 тоже проблем нет.
(79) этому косяку уже много лет.
81 — 24.10.18 — 15:47
(80) Но воспроизводится он только на демоконфигурациях версий 1.1.107.х.
82 — 25.10.18 — 06:50
Раньше была проблема на 32-ух битных версиях PostgreSQL, не хватало им памяти для больших конфигураций. Приходилось снимать с поддержки конфу, чтобы работать. С появлением 64-битной проблема ушла.
И вот опять что-то похожее.
83 — 25.10.18 — 07:14
(0) Какая операционная система?
84 — 25.10.18 — 07:16
85 — 25.10.18 — 07:18
(84) Ты не автор. «вин» бывает разный.
86 — 25.10.18 — 10:50
(83) win7, win10, win2008r2
87 — 31.10.18 — 10:50
Насколько я разобрался 1С пихает файл конфигурации в поле. Поле имеет ограничение 1 Гб. Размер конфы закрытой для ред. и снятой с поддержки не превышает 1 Гб, а частично дописанная превышает. 1С рекомендует (прочитал на форуме SQL) снимать с поддержки полностью или использовать pg_basebackup. Снял на тестовой с поддержки — дамп отработал без ошибок.
88 — 31.10.18 — 11:10
89 — 31.10.18 — 11:15
(87) Просто рекомендация 1С не совсем честная. Если снять конфу КА 1.1 с поддержки или УПП 1.3 с поддержки, то проблема действительно пропадает. Однако, есть другие конфы, с которыми этой проблемы в принципе нет — см (74),
а так же и другие.
90 — 31.10.18 — 13:40
(89) и решения от 1с скорее всего не дождемся. Работу с данными в этом случае организует кластер серверов 1с? имею в виду структуру таблиц.
91 — 06.11.18 — 10:44
(87) На каком варианте остановился?
92 — 07.11.18 — 21:14
(87)В тему: те же проблемы с УПП 1.3.112.4 на pg 9.6:
-при архивировании средствами pg — описанная выше ошибка
-при обновлении — вылетает
При анализе выяснилось, что ошибка возникает с таблицей config (конфигурация БД), при обработке определенной строки таблицы, подробности ниже.
1. Просмотрел таблицу config, поля: filename (строка), creation (датавремя), modified(датавремя), attributes(целое), datasize(целое), binarydata(bytea).
2. Строк 34017.
3. Сумма размера бинарных полей примерно 98% размера файла .cf (остальное занимают оставшиеся поля), т.е. в binarydata хранится конфигурация.
4. Проверил: для любой строки размер binarydata не более 100МБ. Кроме одной, там размер binarydata 555МБ. И именно в этой строке возникает ошибка. Выяснил, что в данной строке, в одном поле хранится конфигурация поставщика.
5. Поэтому при снятии с поддержки или запрете изменений (замок) ошибка исчезает, т.к. при этом удаляется строка по п.4.
Суммируя вышеизложенное: максимальный размер данных, внесенных в ОДНО поле — 0,55ГБ (см. п.4.), что не дотягивает до озвученного лимита объема данных в ОДНОМ поле 1ГБ.
Вывод: либо лимит объема ОДНОГО поля около 0,5ГБ, либо причина в другом.
Пробовал играть настройками конфигурации pg (размеры буферов памяти и т.п.) — ошибка не исчезла.
93 — 07.11.18 — 21:47
(92)Кстати, и обычный select средствами pg вызывает эту же ошибку, если в его результате содержится поле Binarydata с конфигурацией поставщика (555МБ) — еще одно подтверждение что ограничение 1ГБ ни при чем.
94 — 07.11.18 — 21:51
(93) да. конфа ка2 нормально переносит снятие с замка.
95 — 07.11.18 — 22:46
(0) ровно та же проблема у меня была с УПП в 2012 году — с той же ошибкой pg_dump грохался. Стабильность — признак мастерства, чо… Сколько лет прошло, а ничего не меняется.
96 — 08.11.18 — 00:41
(95) Так поди все на форумах пошушукались и разработчикам никто не отписал.
97 — 08.11.18 — 01:22
shared_buffers = 512Mb ?
98 — 08.11.18 — 08:37
(96) отписывались. Я помню об этих глюках примерно с 2011-2012 годов. Когда это поперло, то начали откладывать на ИТС полные дистрибы КА 1.1 и УПП 1.3 , т.к. реально был всплеск обращений, что не проходит процедура обновления конфиги апдейтами.
99 — 08.11.18 — 10:25
(97) shared_buffers = 768MB
100 — 08.11.18 — 10:29
(96) Я две недели назад написал на v8@1c.ru.
Отписались, что проблема передана разработчикам, и, пока, все.