Ошибка субд lost synchronization with server got message type d length 10000050

1. 17.09.2019, 11:17

   
   

   #1

   

   
   Гость форума
   

   ---

   Ошибка СУБД:` Lost synchronization with server: got message type «D»
   

   Столкнулся с проблемой в первые.
   ЧТо может означать данная проблема
   полностью звучит она так:

   Платформа: 1С:Предприятие 8.3 (8.3.14.1565)
   Конфигурация: Зарплата и управление персоналом, редакция 3.1 (3.1.8.216) (http://v8.1c.ru/hrm/)
   Copyright © ООО «1C-Софт», 2007-2018. Все права защищены
   (http://www.1c.ru)
   Режим: Серверный (сжатие: усиленное)
   Приложение: Тонкий клиент
   Локализация: Информационная база: русский (Россия), Сеанс: русский (Россия)
   Вариант интерфейса: Такси

   Ошибки:
   ———————————————————————————
   17.09.2019 10:10:51
   Невосстановимая ошибка
   Ошибка при выполнении запроса POST к ресурсу /e1cib/logForm:
   по причине:
   Ошибка СУБД:
   lost synchronization with server: got message type «D», length 5301060

   ---

2. 17.09.2019, 11:46

   
   

   #2

   

   
   Гость форума
   

   ---

   Re: Ошибка СУБД:` Lost synchronization with server: got message type «D»
   

   ---

3. 02.10.2019, 14:51

   
   

   #3

   

   
   Гость форума
   

   ---

   Re: Ошибка СУБД:` Lost synchronization with server: got message type «D»
   

   ---

4. 03.10.2019, 09:01

   
   

   #4

   

   
   Гость форума
   

   ---

   Re: Ошибка СУБД:` Lost synchronization with server: got message type «D»
   

   ---

5. 14.01.2020, 17:12

   
   

   #5

   

   
   Гость форума
   

   ---

   Re: Ошибка СУБД:` Lost synchronization with server: got message type «D»
   

   Сообщение от niiikkki
   

   платформы

   на какую?

   ---

My automated pg_dump process has been failing when attempting to backup a postgres database. The error message I’m receiving:

ERROR Message:

pg_dump: Error message from server: ERROR: invalid memory alloc
request size 1249770967 pg_dump: The command was: COPY
public.data_store (id, length, last_modified, data) TO stdout;
Custom backup of jackrabbit pg_dump: SQL command failed pg_dump: Error
message from server: ERROR: invalid memory alloc request size
1249770967 pg_dump: The command was: COPY public.data_store
(id, length, last_modified, data) TO stdout; [!!ERROR!!] Failed to
produce custom backup database jackrabbit Plain backup of pdi_logging
Custom backup of pdi_logging Plain backup of postgres Custom backup of
postgres Plain backup of quartz Custom backup of quartz

Based on my findings everything seemed to point to corrupt data in the table so I created a function to query the table and extract the ctid so I then may find the culprit and delete the corrupt row.

Function:

CREATE OR REPLACE FUNCTION find_bad_row(tablename text)
 RETURNS tid AS
$BODY$
DECLARE
result tid;
curs REFCURSOR;
row1 RECORD;
row2 RECORD;
tabName TEXT;
count BIGINT := 0;
BEGIN
SELECT reverse(split_part(reverse($1), '.', 1)) INTO tabName;

OPEN curs FOR EXECUTE 'SELECT ctid FROM ' || tableName;

count := 1;
FETCH curs INTO row1;

WHILE row1.ctid IS NOT NULL LOOP
result = row1.ctid;

count := count + 1;
FETCH curs INTO row1;

EXECUTE 'SELECT (each(hstore(' || tabName || '))).* FROM '
|| tableName || ' WHERE ctid = $1' INTO row2
USING row1.ctid;

IF count % 100000 = 0 THEN
RAISE NOTICE 'rows processed: %', count;
END IF;
END LOOP;

CLOSE curs;
RETURN row1.ctid;
EXCEPTION
WHEN OTHERS THEN
RAISE NOTICE 'LAST CTID: %', result;
RAISE NOTICE '%: %', SQLSTATE, SQLERRM;
RETURN result;
END
$BODY$
 LANGUAGE plpgsql VOLATILE
 COST 100;
ALTER FUNCTION find_bad_row(text)
 OWNER TO pentaho;

After calling the function select find_bad_row('public.data_store'), the result given was (0,2). I searched the table for said ctid, select ctid, * from public.data_store, and deleted the preceding row. I then executed my pg_dump script and received the same error. Re-running the function on the table returns a result again of the first row. Being new to postgres is my approach altogether wrong and is there another way to resolve this? Could it be that the entire table is corrupt?

Can someone shed some light on what's happening here?

D:backups>pg_dump -Z 9 -Fc -C -U postgres -f sheepcrcdbback.dmp sheepcrc2

pg_dump: Dumping the contents of table «uploadeddatafiles» failed:
PQgetCopyData

() failed.

pg_dump: Error message from server: lost synchronization with server:
got messag

e type "d", length 6036499

pg_dump: The command was: COPY public.uploadeddatafiles (id, username,
projectid
, aspsession, filename, filetype, filesize, filedata, uploadedon,
«timestamp») T

O stdout;

pg 8.3.1 server on w2k3
pg_dump 8.3.1 and 8.3.3 on the same machine both do the same thing.

data directory and backup directory excluded from virus scanner.

The followinng variations also failed. The length seems to be either
6036499 or 8435588 (84… is most common).

pg_dump -Z 9 -Fp -C -U postgres -f sheepcrcdbback.dmp sheepcrc2
pg_dump -Fp -C -U postgres -f sheepcrcdbback.dmp sheepcrc2

uploadeddatafiles holds excel spreadsheets in the filedata column.

sheepcrc2=# select count(*) from uploadeddatafiles;
count
-------
  405
(1 row)

sheepcrc2=# select sum(length(filedata)) from uploadeddatafiles;
   sum
-----------
271067619
(1 row)

This completes and returns all rows
select id, md5(filedata) from uploadeddatafiles

klint.

--
Klint Gore
Database Manager
Sheep CRC
A.G.B.U.
University of New England
Armidale NSW 2350

Ph: 02 6773 3789
Fax: 02 6773 3266

EMail: kgore4@xxxxxxxxxx

I am able to reproduce your issue with the following code:

print(f"Python version {sys.version}")
# Python version 3.7.4 (tags/v3.7.4:e09359112e, Jul  8 2019, 20:34:20) [MSC v.1916 64 bit (AMD64)]

print(f"pyodbc version {pyodbc.version}")
# pyodbc version 4.0.27

connection_string = get_conn_str()
print(connection_string)
# DSN=PostgreSQL35W

cnxn = pyodbc.connect(connection_string)
print(f'{cnxn.getinfo(pyodbc.SQL_DRIVER_NAME)}, version: {cnxn.getinfo(pyodbc.SQL_DRIVER_VER)}')
# PSQLODBC35W.DLL, version: 11.01.0000

enc = 'utf-8'
cnxn.setdecoding(pyodbc.SQL_CHAR, encoding=enc)
cnxn.setdecoding(pyodbc.SQL_WCHAR, encoding=enc)
cnxn.setencoding(encoding=enc)

crsr = cnxn.cursor()

num_params = 7499
print(f"Attempting {num_params} parameters ...")
qmark_string = ",".join(["(?)" for x in range(num_params)])
sql = "SELECT * FROM (VALUES " + qmark_string + ") t(val)"
params = tuple(range(num_params))
crsr.execute(sql, params)
n = 0
for row in crsr:
    n += 1
print(f"{n} row(s) returned")

The code works with num_params ≤ 7498, but fails for anything larger.

However, I was also able to reproduce the issue using System.Data.Odbc in .NET, although the failure point there was 32768 and the error was

Unhandled Exception: System.OverflowException: Arithmetic operation resulted in an overflow.
   at System.Data.Odbc.OdbcParameterCollection.Bind(OdbcCommand command, CMDWrapper cmdWrapper, CNativeBuffer parameterBuffer)
   at System.Data.Odbc.OdbcCommand.ExecuteReaderObject(CommandBehavior behavior, String method, Boolean needReader, Object[] methodArguments, SQL_API odbcApiMethod)
   at System.Data.Odbc.OdbcCommand.ExecuteReaderObject(CommandBehavior behavior, String method, Boolean needReader)
   at System.Data.Odbc.OdbcCommand.ExecuteReader(CommandBehavior behavior)
   at odbcConsoleApp.Program.Main(String[] args) in C:UsersGordsourcereposodbcConsoleAppProgram.cs:line 31

So it looks like there is some sort of limitation on the number of parameters that the ODBC driver can handle.