sue. The original issue is here:
https://github.com/ged/ruby-pg/issues/404
--
Kind Regards
Lars Kanis
From 079c3dce7c4580a797267b6e42b33399606b4f9d Mon Sep 17 00:00:00 2001
From: Lars Kanis
Date: Wed, 17 Nov 2021 21:04:45 +0100
Subject: [PATCH] Windows: Gracefully close the socket on process e
ast in the
context of regression testing or so. But I think that loosing messages
from the backend is way more critical than a non-sync process
termination. Do I miss something?
--
Regards,
Lars Kanis
o it,
observe the parent process and close the socket when it exited, could
work, but I guess it's overly complicated and creates more issues than
it solves. Probably the same if the master process handles the socket
closing.
So I still think it's best to close the socket as proposed in the patch.
--
Regards,
Lars Kanis
at Heroku:
https://github.com/heroku/stack-images/issues/147
--
Kind Regards,
Lars Kanis
From f0c0dc3511c66a1e0fe0e4cc7ad2995f5f40bd7c Mon Sep 17 00:00:00 2001
From: Lars Kanis
Date: Thu, 17 Oct 2019 19:37:51 +0200
Subject: [PATCH] Fix wrong connection status on invalid "connect_t
ly in parse_int_param().
--
Kind Regards,
Lars Kanis
Am 17.10.19 um 20:04 schrieb Lars Kanis:
> Greetings,
>
> libpq since PostgreSQL-12 has stricter checks for integer values in
> connection parameters. They were introduced by commit
> https://github.com/post
nce we are done
> here, the topic is larger.
We have around 650 tests on ruby-pg to ensure everything runs as
expected and I always wondered how the API of libpq is being verified.
--
Kind Regards,
Lars Kanis
diff --git a/src/interfaces/libpq/fe-connect.c b/src/interfaces/libpq/fe-con
nce we are done
> here, the topic is larger.
We have around 650 tests on ruby-pg to ensure everything runs as
expected and I always wondered how the API of libpq is being verified.
--
Kind Regards,
Lars Kanis
diff --git a/src/interfaces/libpq/fe-connect.c b/src/interfaces/libpq/fe-con
nce we are done
> here, the topic is larger.
We have around 650 tests on ruby-pg to ensure everything runs as
expected and I always wondered how the API of libpq is being verified.
--
Kind Regards,
Lars Kanis
diff --git a/src/interfaces/libpq/fe-connect.c b/src/interfaces/libpq/fe-con
737561270
From ab793829a4ce473f1cc2bbc0e2a6f6753553255d Mon Sep 17 00:00:00 2001
From: Lars Kanis
Date: Sun, 8 Sep 2024 13:59:05 +0200
Subject: [PATCH] libpq: Process buffered SSL read bytes to support records
>8kB on async API
The async API of libpq doesn't support SSL record sizes >8kB so far.
This size isn't
Thank you Jacob for verifying this issue!
Gory details of the packet sizes, if it's helpful:
- max TLS record size is 12k, because it made the math easier
- server sends DataRow of 32006 bytes, followed by DataRow of 806
bytes, followed by CommandComplete/ReadyForQuery
- so there are three TLS r
From: Lars Kanis
Date: Sat, 23 Jun 2018 19:34:11 +0200
Subject: [PATCH] libpq: Add function PQresultMemsize()
This function retrieves the number of bytes allocated for a given result.
That can be used to instruct the GC about the memory consumed behind a
wrapping object and for diagnosing m
diagnostic information to each object.
What do you think about adding such a function?
--
Kind Regards,
Lars
From d3ac8089a1b8c26d29d8d8e93c48a892cec75e53 Mon Sep 17 00:00:00 2001
From: Lars Kanis
Date: Sat, 23 Jun 2018 19:34:11 +0200
Subject: [PATCH] libpq: Add function PQresultMemsize()
Thi
#MULTIBYTE-CHARSET-SUPPORTED
--
Kind Regards,
Lars
From 65d60fc66cf62af9ea2d570590a541fbdf397767 Mon Sep 17 00:00:00 2001
From: Lars Kanis
Date: Sat, 1 Sep 2018 18:03:14 +0200
Subject: [PATCH] Fix docs to JOHAB encoding on server side
This is probably left over from commit
This patch limits the workaround of using __buildin_setjmp on the
Windows MINGW platform. This workaround is only necessary for legacy
MSVCRT based toolchain, but not for UCRT based. It is not available at
all on clang on ARM64 resulting in the following compiler error:
error: __builtin_longjmp
14 matches
Mail list logo
