mORMot + PostgreSQL: "lost synchronization with server" when switching

Kabiri · 2026-04-13 17:36:26

I'm using mORMot with PostgreSQL, and I suddenly started getting this error:

Project Vi.exe raised exception class ESqlDBPostgres with message:
TSqlDBPostgresLib Exec failed:
[lost synchronization with server: got message type "lost synchronization with server: got message type"]

After this error occurs, the application can no longer connect to the database unless restarted.

Here is how I initialize the connection:

Model := CreateViModel;
DBProps := TSqlDBPostgresConnectionProperties.Create(
  Host, DBName, DBUser, DBPass
);

DBProps.UseCache := False;
DBProps.ReconnectAfterConnectionError := True;

VirtualTableExternalRegister(Model, TOrmTenant, DBProps);
...

Additional details:

The issue seems to happen when rapidly switching between menus in the client (HTMX-based UI).
It looks like multiple concurrent requests may be involved.
After the error, even reconnection does not recover properly.

Questions:

Could this be related to connection reuse or thread safety in mORMot?
Should I be using a connection pool or per-thread connection instead?
Is there a known issue with PostgreSQL driver synchronization in such scenarios?

Any guidance or similar experiences would be appreciated.

Last edited by Kabiri (2026-04-14 07:24:36)

ab · 2026-04-13 22:27:12

If I understand correctly https://www.postgresql.org/message-id/1 … nabble.com
it sounds like the server closed the connection due to too big/slow request.
Look at the request itself, and the full error message.

It may be more tied to the request and server itself that with mORMot.

There is a per-thread connection pool in mORMot.
So nothing is to be configured here.
Just don't create too many threads in your code.

Kabiri · 2026-04-14 08:49:12

I was using PostgreSQL 17.6-2. I’ll upgrade to PostgreSQL 18.3-2 and test it.
Maybe the issue was related to this: https://www.postgresql.org/message-id/2 … .pgh.pa.us

Kabiri · 2026-04-14 12:42:57

@ab
I updated it and everything was working fine.
After some time—without rapidly switching between menus and without any errors—everything stopped working.

The application reaches this line but never returns from it:

u := TOrmUser.Create;
try
  if not Self.Server.Orm.Retrieve('Email=?',[],[Email],u) then

Kabiri · 2026-04-15 18:11:45

Isn’t there any solution?
It’s really frustrating. Right now, even during testing with no users, it keeps getting stuck and I have to restart the service. What should I do when there are many users?

ab · 2026-04-16 08:33:27

Could you try with the Zeos client and see if it is a mormot direct access unit problem?

I am AFK those days, so I can't test anything.

danielkuettner · 2026-04-16 10:12:58

With Zeos we never had such an issue. So it seems to be mormot direct access unit problem.

Kabiri · 2026-04-16 10:44:24

ab wrote:

Could you try with the Zeos client and see if it is a mormot direct access unit problem?
I am AFK those days, so I can't test anything.

Ok, thanks. I’ll check it and let you know.

Kabiri · 2026-04-16 12:28:26

The `Zeos.inc` file used in `mormot.db.sql.zeos` cannot be found.

Prometeus · 2026-04-16 13:12:05

Kabiri wrote:

The `Zeos.inc` file used in `mormot.db.sql.zeos` cannot be found.

Have you installed 'Zeos' before using it as a DB connection? 'Zeos.inc' is in the 'src' folder of the 'Zeos' installation.

Kabiri · 2026-04-16 13:26:18

Prometeus wrote:

Have you installed 'Zeos' before using it as a DB connection?

No, I haven’t installed it. I thought it didn’t require installation. I’ll install it now.

Kabiri · 2026-04-17 17:24:16

After several hours of working with the application, and repeatedly opening and closing menus, the following error suddenly appeared:

Project Vi.exe raised exception class EZSQLException with message 
'SQL Error: insufficient data in "T" message

Code: 7 
SQL: select ID,Name,Slug,Plan,OwnerID,IsActive,MaxMembers,CreatedAt 
from public.Tenant where ID=?'.

After that, the application no longer responds to any requests.

This is how I established the connection:

DBProps := TSqlDBZeosConnectionProperties.Create('zdbc:postgresql://' + Host, DBName, DBUser, DBPass);

Kabiri · 2026-04-17 18:08:15

It happened again. This time the error was:

Project Vi.exe raised exception class EZSQLException with message 
'SQL Error: message contents do not agree with length in message type "T"
server sent data ("D" message) without prior row description ("T" message)

Code: 7 
SQL: select ID,TenantID,Email,FullName,PasswordHash,Role,AvatarUrl,CreatedAt 
from public.User where ID=?'.

After that, the application raised the following exception:

Project Vi.exe raised exception class $C0000005 with message 
'c0000005 ACCESS_VIOLATION'.

The client is using HTMX.

ab · 2026-04-17 19:02:00

Are you sure the libpq library is in the same version than the server?

danielkuettner · 2026-04-18 07:41:57

Wether Zeos nor mORMot2 error.
Something in your own project went wrong.

I would guess libpq is out of sync with server because of using it in a multi-threaded application in a absolutely wrong way.

flydev · 2026-04-18 09:35:58

...in message type "T" server sent data "D" message without prior row description ("T" message)

the message itself really give hint about what @daniel is suggesting: wrong multi-thread usage.

you really need to give more information and eliminate causes. First answer @ab and tell us:

- version of libpq in use

then,
- check if is zeos-specific by running the same sql:
1. psql,
2. pgAdmin,
3. a tiny test executable using only one connection and one thread

- eliminate the dll ambiguity:
1. copy the chosen libpq.dll to the EXE folder (keep only the dependent DLLs required by that build)
2. temporarily rename any other libpq.dll reachable through PATH

But again, it seem to be a thread issue:

inference from the protocol behavior and Tom Lane’s explanation wrote:

Same connection used concurrently from multiple threads
If two threads share one PostgreSQL connection or one query object and interleave reads/writes on the same socket, the message stream becomes corrupted from the client’s perspective. The symptom often looks exactly like “unexpected message type while idle” or “DataRow without prior RowDescription,” because packets are being attributed to the wrong command.

https://www.postgresql.org/docs/current … -flow.html

Kabiri · 2026-04-18 10:35:36

ab wrote:

Are you sure the libpq library is in the same version than the server?

Yes.
After installing the new version, I copied it from
C:\Program Files\PostgreSQL\18\pgAdmin 4\runtime
and placed it next to my application.

Kabiri · 2026-04-18 10:53:11

@flydev @danielkuettner

I removed the DLL files from next to the application and the error appeared, so it seems it is using those DLLs. Maybe it’s related.

I registered the services like this:

Server.ServiceDefine(TViAuthService, [IViAuthService], sicShared);

Would `sicPerThread` help?

In my application I don’t have multiple threads, but the client can send asynchronous requests. I assumed that on the server side it would be handled internally.

Last edited by Kabiri (2026-04-18 11:13:52)

danielkuettner · 2026-04-18 13:17:40

Now you are on the right way.
Client requests are handled in threads on service side. Every thread needs its own (separate) connection to postgres to work properly.
Or you use only one connection to db and synchronize threads with critical sections.
Or you handle all db access in one thread (e.g. MainThread). There are options on mORMot for that.
You have options and all depends on what you want.

Kabiri · 2026-04-18 17:08:57

I changed all services from:

Server.ServiceDefine(TViAuthService, [IViAuthService], sicShared);

to

Server.ServiceDefine(TViAuthService, [IViAuthService], sicPerThread);

but the error still occurs.

Once again, the error happens inside `libpq.dll`.

ab · 2026-04-18 17:31:21

sicShared/sicPerThread has no effect to the actual threading, only to the TViAuthService class instance executed on the server.
Only sicInMainThread or sicInBackgroundThread could force execution in a single thread.
But the mormot postgresl connector maintain a per-thread connection, unless you disable this, so there should be no problem with concurrent access. And even more, the ORM.

How to you access the SQL? Only using the ORM?

We need a minimal reproducible example to investigate further.
It seems that you are the first to report this issue.

Kabiri · 2026-04-18 17:37:56

I only used the ORM.
I should create a smaller sample project, and if the same issue still occurs, I will send it to you.

Kabiri · 2026-04-22 17:14:36

@ab
I created a small program and sent a large number of concurrent requests, and there were no errors.

This program is different from the main application.

In the main application, I wrote a function for `Server.OnBeforeURI`, and inside that function I have the following code:

var AuthService := TViAuthService.Create;
try
  CurrentTenantID := TenantID;
  CurrentUserID   := UserID;
  var ORM := Ctxt.Server.Orm;
  AuthService.IsValidLogin(ORM, CurrentTenantID, CurrentUserID, CurrentUserRole);
finally
  AuthService.Free;
end;

Could this be the reason for these errors?

----Edit----
I removed this code as well, but it still happened.

Last edited by Kabiri (2026-04-22 19:40:43)

ab · 2026-04-22 20:15:08

So it is likely that the issue does not come directly from mORMot, but from some pointer issues in the code.

Did you try to run with the heap manager in FullDebugMode to check for heap corruption?

ttomas · 2026-04-23 11:23:21

What type of http server you use (TRestHttpServerUse)? I have a problem with useHttpAsync and FirebirdSql connection in interface service! Switching to useHttpSocket, problem disappear, different threading model. Problem was bug in my code, after bug resolve, both useHttpAsync and useHttpSocket are OK.

Kabiri · 2026-04-23 13:24:19

@ab I didn’t use pointers in my code.

Everything is wrapped in try/finally blocks.
I have 21 models, 87 endpoints, and 10 services.
I used interfaces.

Also, I created the HTTP server like this:

Http := TRestHttpServer.Create(Port, [Server], '+', useHttpSocket);

And the server is created as:

Server := TRestServerDB.Create(Model, ':memory:', False);

@ttomas : What exactly was your issue?

flydev · 2026-04-23 13:32:19

Just sayin, without any code to read and/or reproducible sample it's really hard to help.. if you have any ai tool at hand then just ask it to extract a sample, and even better, install a debugging skill on it and throw it on your codebase.

ttomas · 2026-04-23 13:56:25

Kabiri wrote:

@ttomas : What exactly was your issue?

I don't use orm part and need to close db connection after interface use TSqlDBConnectionProperties.ThreadSafeConnection.Disconnect, without lock :-). I need my service to not use any db connection if users are out.
I just notice on slow req/rate useHttpSocket round robin all working threads, create connections on all threads. But async server create only one connection on first working thread. Http working thread=DB pool thread connection.

danielkuettner · 2026-04-23 15:56:34

I guess your code is wrong (e.g. in Server.OnBeforeURI).
It's definitely a threading issue (when you look at the postgres error). Such issues wouldn't exist, if you would make in right (there are examples for that).

The Interfaced Services should be created only once at startup with ServiceDefine. After that you work in your methods of that class (TViAuthService) using ORM or Props.Execute...
All the other stuff does the little mORMot in background for you.
A manuell creation on Server.OnBeforeURI is not wanted by the creator of the little mORMot. Am I wrong @ab?

ab · 2026-04-23 16:12:50

@danielkuettner is correct of course: you need to let the service instances be created by the server, using the Resolve() method.
But I suspect the TViAuthService class is in fact not a mORMot service class, more like a "repository pattern" local class.

danielkuettner · 2026-04-23 17:34:37

Hi ab,

Kabiri wrote:

Server.ServiceDefine(TViAuthService, [IViAuthService], sicShared);

and later than I read

Kabiri wrote:

var AuthService := TViAuthService.Create;...

That's why I came on this.
But you are right, it's just a wild guess.

Kabiri · 2026-04-23 18:44:26

flydev wrote:

Just sayin, without any code to read and/or reproducible sample it's really hard to help.. if you have any ai tool at hand then just ask it to extract a sample, and even better, install a debugging skill on it and throw it on your codebase.

I created a sample code, but it didn’t produce any errors.

I perform JWT validation in Server.OnBeforeURI.

Kabiri · 2026-04-24 10:44:05

Does this connection method help?

{$ifdef DBZeos}
  DBProps := TSqlDBZeosConnectionProperties.Create('zdbc:postgresql://'+Host,
                  DBName, DBUser, DBPass);
{$else}
  DBProps := TSqlDBPostgresConnectionProperties.Create(Host, DBName, DBUser, DBPass);
{$endif}
DBProps.UseCache := False;
DBProps.ReconnectAfterConnectionError := True;

{$ifdef DBZeos}
DBProps.ThreadingMode := tmMainConnection;
{$else}
(DBProps as TSQLDBConnectionPropertiesThreadSafe).ThreadingMode := tmMainConnection;
{$endif}

Last edited by Kabiri (2026-04-24 10:44:21)

ttomas · 2026-04-25 18:22:33

Why you use tmMainConnection? By default you have 32(you can change on creation of http server) http working threads and only one db connection (no db pool) in main thread. This working threads must wait from main thread to get/set data from single mainthread db connection.
If you use tmThreadPool, then all 32 working thread will create db connection and you will not have waiting/switch between threads for db connection. Yes some databases have problem with threading, but posgresql as I know don't have a problem.

Last edited by ttomas (2026-04-25 18:25:16)

Kabiri · 2026-04-25 19:16:40

As far as I understood, this happens because two or more threads are using the same database connection at the same time.
I thought that with this approach there would be only one thread for database access.

However, the error does not occur immediately after startup.
Sometimes it happens after 5 minutes, sometimes after 30 minutes.

I tried using tmMainConnection. This time it does not show an error, but the server suddenly freezes and after a short time it gets terminated.

Now I have removed tmMainConnection, but still no error has appeared yet, so I haven’t included a new log.

Last edited by Kabiri (Yesterday 18:31:15)

ab · 2026-04-25 19:42:45

Use the async HTTP server to have a stable pool of threads.

Kabiri · 2026-04-25 20:07:23

Well, now I’m getting this error:

Project Vi.exe raised exception class ESqlDBPostgres with message
“TSqlDBPostgresLib Exec failed: [message contents do not agree with length in message type "T"
server sent data ("D" message) without prior row description ("T" message)]”.

It happened.

TSqlDBPostgresStatement object 016914ac4940 was previously used by conn-2 (ThreadID=29bc) across multiple queries (lines 201–232).

After conn-2 called EndCurrentThread, the same statement object was reused by conn-4 (ThreadID=23376) — visible at line 273.

When conn-4 (ThreadID=23376) and conn-5 (ThreadID=24728) both called Prepare simultaneously on statement objects 016914ac4940 and 016914ac4ac0 respectively, a PostgreSQL protocol-level exception was raised:
message contents do not agree with length in message type "T" / server sent data ("D" message) without prior row description ("T" message)
line 309-323

Both threads were handling the same two service methods (ViTaskService.ViewTask and ViTaskService.GetDetail) concurrently, using sicPerThread instance mode.

The Statement field in the exception object is null, suggesting the statement reference was lost or corrupted at the time of the error.

Environment:

mORMot version: 2.4.14728
PostgreSQL: 127.0.0.1:5432, libpq v170006
OS: Windows 10 x64
App: x64
Service instance mode: sicPerThread
Thread pool size: 32

Last edited by Kabiri (Yesterday 18:30:37)

Kabiri · 2026-04-25 20:21:13

ab wrote:

Use the async HTTP server to have a stable pool of threads.

OK, I’ll do it.

ab · Yesterday 06:44:17

Are you sure sicPerThread is needed?

Please follow the rules and don't put logs directly in the forum stream.

flydev · Yesterday 08:56:14

The logs you just posted here only show what was already in your very first message, as also mentioned in the quote from my reply #16.

Kabiri wrote:
flydev wrote:
Just sayin, without any code to read and/or reproducible sample it's really hard to help.. if you have any ai tool at hand then just ask it to extract a sample, and even better, install a debugging skill on it and throw it on your codebase.
I created a sample code, but it didn’t produce any errors.

What I tried to ask there was not a new or overly simple piece of code, but a reproducible sample based on your actual code, with the relevant services, server initialization, database initialization, and related code simplified as much as possible.

What I mean is: if your code is not top-secret, copy your project, simplify it until the issue still happens, provide some dummy data, and then share it here privately if needed. By doing that, you will likely be able to identify where the issue really occurs.. or we will be able to help you and not only guess things as we already know the root cause.

Kabiri · Yesterday 18:28:13

ab wrote:

Are you sure sicPerThread is needed?
Please follow the rules and don't put logs directly in the forum stream.

At first, I was using sicShared with useHttpSocket.
I thought it might work better if each instance had its own thread, so I switched to sicPerThread.

Now I’ve changed it back to sicShared and switched to useHttpAsync.
I’ll test it and see whether the database issue still happens.

Understood, I’ll remove the logs.

flydev wrote:

What I tried to ask there was not a new or overly simple piece of code, but a reproducible sample based on your actual code, with the relevant services, server initialization, database initialization, and related code simplified as much as possible.

The code is not owned by me, so I cannot share the original project directly.

However, I already simplified the same codebase.
The server initialization, service registration, and the database access layer were not changed.
Only the models were reduced to two simple models, and the service layer was reduced to two services.

I also wrote a new and much simpler client to communicate with the server.

However, after testing the simplified version for about one hour, the issue did not occur.

In the main application, I also tried repeating the same actions many times, and the issue still did not happen consistently.
At first, I thought it was related to navigating from one menu to another, but later I realized that is not the case. It just happens from time to time.

Sometimes it happens 5 minutes after startup, and sometimes after one hour.

Since I could not reproduce the issue in the simplified version, I did not upload it anywhere yet.
I will continue testing it further, and if I manage to reproduce the issue there as well, I will upload it.

However, the error message itself suggests that two threads are using the same database connection at the same time, and this is not something I directly control in the application.

Last edited by Kabiri (Yesterday 18:35:03)

ab · Yesterday 19:18:25

I didn't get two identical statements hexadecimal pointers in the logs, so I guess two threads did not use the same database connection at the same time.

If you put the full logs in a separated gist or link, it could be good for us to investigate.

mORMot Open Source

#1 2026-04-13 17:36:26

mORMot + PostgreSQL: "lost synchronization with server" when switching

#2 2026-04-13 22:27:12

Re: mORMot + PostgreSQL: "lost synchronization with server" when switching

#3 2026-04-14 08:49:12

Re: mORMot + PostgreSQL: "lost synchronization with server" when switching

#4 2026-04-14 12:42:57

Re: mORMot + PostgreSQL: "lost synchronization with server" when switching

#5 2026-04-15 18:11:45

Re: mORMot + PostgreSQL: "lost synchronization with server" when switching

#6 2026-04-16 08:33:27

Re: mORMot + PostgreSQL: "lost synchronization with server" when switching

#7 2026-04-16 10:12:58

Re: mORMot + PostgreSQL: "lost synchronization with server" when switching

#8 2026-04-16 10:44:24

Re: mORMot + PostgreSQL: "lost synchronization with server" when switching

#9 2026-04-16 12:28:26

Re: mORMot + PostgreSQL: "lost synchronization with server" when switching

#10 2026-04-16 13:12:05

Re: mORMot + PostgreSQL: "lost synchronization with server" when switching

#11 2026-04-16 13:26:18

Re: mORMot + PostgreSQL: "lost synchronization with server" when switching

#12 2026-04-17 17:24:16

Re: mORMot + PostgreSQL: "lost synchronization with server" when switching

#13 2026-04-17 18:08:15

Re: mORMot + PostgreSQL: "lost synchronization with server" when switching

#14 2026-04-17 19:02:00

Re: mORMot + PostgreSQL: "lost synchronization with server" when switching

#15 2026-04-18 07:41:57

Re: mORMot + PostgreSQL: "lost synchronization with server" when switching

#16 2026-04-18 09:35:58

Re: mORMot + PostgreSQL: "lost synchronization with server" when switching

#17 2026-04-18 10:35:36

Re: mORMot + PostgreSQL: "lost synchronization with server" when switching

#18 2026-04-18 10:53:11

Re: mORMot + PostgreSQL: "lost synchronization with server" when switching

#19 2026-04-18 13:17:40

Re: mORMot + PostgreSQL: "lost synchronization with server" when switching

#20 2026-04-18 17:08:57

Re: mORMot + PostgreSQL: "lost synchronization with server" when switching

#21 2026-04-18 17:31:21

Re: mORMot + PostgreSQL: "lost synchronization with server" when switching

#22 2026-04-18 17:37:56

Re: mORMot + PostgreSQL: "lost synchronization with server" when switching

#23 2026-04-22 17:14:36

Re: mORMot + PostgreSQL: "lost synchronization with server" when switching

#24 2026-04-22 20:15:08

Re: mORMot + PostgreSQL: "lost synchronization with server" when switching

#25 2026-04-23 11:23:21

Re: mORMot + PostgreSQL: "lost synchronization with server" when switching

#26 2026-04-23 13:24:19

Re: mORMot + PostgreSQL: "lost synchronization with server" when switching

#27 2026-04-23 13:32:19

Re: mORMot + PostgreSQL: "lost synchronization with server" when switching

#28 2026-04-23 13:56:25

Re: mORMot + PostgreSQL: "lost synchronization with server" when switching

#29 2026-04-23 15:56:34

Re: mORMot + PostgreSQL: "lost synchronization with server" when switching

#30 2026-04-23 16:12:50

Re: mORMot + PostgreSQL: "lost synchronization with server" when switching

#31 2026-04-23 17:34:37

Re: mORMot + PostgreSQL: "lost synchronization with server" when switching

#32 2026-04-23 18:44:26

Re: mORMot + PostgreSQL: "lost synchronization with server" when switching

#33 2026-04-24 10:44:05

Re: mORMot + PostgreSQL: "lost synchronization with server" when switching

#34 2026-04-25 18:22:33

Re: mORMot + PostgreSQL: "lost synchronization with server" when switching

#35 2026-04-25 19:16:40

Re: mORMot + PostgreSQL: "lost synchronization with server" when switching

#36 2026-04-25 19:42:45

Re: mORMot + PostgreSQL: "lost synchronization with server" when switching

#37 2026-04-25 20:07:23

Re: mORMot + PostgreSQL: "lost synchronization with server" when switching

#38 2026-04-25 20:21:13

Re: mORMot + PostgreSQL: "lost synchronization with server" when switching

#39 Yesterday 06:44:17

Re: mORMot + PostgreSQL: "lost synchronization with server" when switching

#40 Yesterday 08:56:14