Sergey Shinderuk writes:
> On 14.01.2022 13:01, Sergey Shinderuk wrote:
>> Unexpectedly, this changes the error message:
> ...
> For the record, after more poking I realized that it depends on timing.
> By injecting delays I can get any of the following from libpq:
> * could not receive data fr
On 14.01.2022 13:01, Sergey Shinderuk wrote:
Unexpectedly, this changes the error message:
postgres=# set idle_session_timeout = '1s';
SET
postgres=# select 1;
could not receive data from server: Software caused connection
abort (0x2745/10053)
For the record, after mor
On 14.01.2022 13:01, Sergey Shinderuk wrote:
When the timeout expires, the server sends the error message and
gracefully closes the connection by sending a FIN. Later, psql sends
another query to the server, and the server responds with a RST. But
now recv() returns WSAECONNABORTED(10053) ins
On 02.12.2021 22:31, Tom Lane wrote:
I'll push the close-only change in a little bit.
Unexpectedly, this changes the error message:
postgres=# set idle_session_timeout = '1s';
SET
postgres=# select 1;
could not receive data from server: Software caused connection abort
Alexander Lakhin writes:
> 29.11.2021 22:16, Tom Lane wrote:
>> After re-reading that thread and re-studying relevant Windows
>> documentation [1][2], I think the main open question is whether
>> we need to issue shutdown() or not, and if so, whether to use
>> SD_BOTH or just SD_SEND. I'm incline
Hello Tom,
29.11.2021 22:16, Tom Lane wrote:
> Hm, yeah, that discussion seems to have slipped through the cracks.
> Not sure why it didn't end up in pushing something.
>
> After re-reading that thread and re-studying relevant Windows
> documentation [1][2], I think the main open question is whethe
Alexander Lakhin writes:
> 27.11.2021 14:39, Lars Kanis wrote:
>> So I still think it's best to close the socket as proposed in the patch.
> Please see also the previous discussion of the topic:
> https://www.postgresql.org/message-id/flat/16678-253e48d34dc0c376%40postgresql.org
Hm, yeah, that d
Hello Lars,
27.11.2021 14:39, Lars Kanis wrote:
>
> So I still think it's best to close the socket as proposed in the patch.
Please see also the previous discussion of the topic:
https://www.postgresql.org/message-id/flat/16678-253e48d34dc0c376%40postgresql.org
Best regards,
Alexander
Am 22.11.21 um 00:04 schrieb Tom Lane:
Do we know that that actually happens in an arm's-length connection
(ie two separate machines)? I wonder if the data loss is strictly
an artifact of a localhost connection. There'd be a lot more pressure
on them to make cross-machine TCP work per spec, one
Thomas Munro writes:
> On Mon, Nov 22, 2021 at 10:42 AM Tom Lane wrote:
>> It'd be useful to check if Lars' patch cures that symptom.
> Yeah, it sounds like it might solve at least the server-side problem.
> Let's call that weird behaviour #1: RST on process exit. (I wonder if
> my keep-the-soc
On Mon, Nov 22, 2021 at 10:42 AM Tom Lane wrote:
> Thomas Munro writes:
> > Hmm, maybe it's still not enough. Now that I have coffee, I thought
> > about the well known failure of idle_in_transaction_timeout to report
> > errors on Windows[1].
>
> Yeah, I think that may well be a manifestation o
Thomas Munro writes:
> Hmm, maybe it's still not enough. Now that I have coffee, I thought
> about the well known failure of idle_in_transaction_timeout to report
> errors on Windows[1].
Yeah, I think that may well be a manifestation of the same problem:
once the backend exits, Winsock issues RS
Thomas Munro writes:
> Hmm. Well, if I understand how this works (and I'm not too familiar
> with this Windows code so I maybe I don't), the postmaster duplicates
> the socket into the child process (see
> {write,read}_inheritable_socket()) and then closes its own handle (see
> ServerLoop()'s cal
On Mon, Nov 22, 2021 at 9:24 AM Thomas Munro wrote:
> Hmm. Well, if I understand how this works (and I'm not too familiar
> with this Windows code so I maybe I don't), the postmaster duplicates
> the socket into the child process (see
> {write,read}_inheritable_socket()) and then closes its own h
On Mon, Nov 22, 2021 at 8:19 AM Lars Kanis wrote:
> The other way around would be to make sure on the client side, that the
> last message is retrieved before the RST packet arrives, so that no data
> is lost. This works mostly well through the sync API of libpq, but with
> the async API the trigg
Am 18.11.21 um 03:04 schrieb Tom Lane:
Thomas Munro writes:
I realise now that the experiments we did a while back to try to
understand this across a few different operating systems[2] had missed
this subtlety, because that Python script had an explicit close()
call, whereas PostgreSQL exits.
Thomas Munro writes:
> I realise now that the experiments we did a while back to try to
> understand this across a few different operating systems[2] had missed
> this subtlety, because that Python script had an explicit close()
> call, whereas PostgreSQL exits. It still revealed that the client
Thomas Munro writes:
> Interesting discovery. I think you might get the same behaviour from
> a Unix system if you set SO_LINGER to 0 before you exit[1]. I suppose
> if a TCP implementation is partially in user space (I have no idea if
> this is true for Windows, I never use it, but I recall tha
On Thu, Nov 18, 2021 at 10:13 AM Lars Kanis wrote:
> Unfortunately each connection is closed hard by a Windows PostgreSQL server
> with TCP flag RST. That in turn is another Winsock API behavior, that is that
> every socket, that wasn't closed by the application is closed hard with the
> RST fl
Lars Kanis writes:
> Explicit closing the socket before process termination leads to a
> graceful close even on Windows. That is done by the attached patch. I
> think delivering the correct error message to the user is much more
> important that closing the process in sync with the socket.
Per
Dear hackers,
I lately had a hard time to find the root cause for some wired behavior
with the async API of libpq when running client and server on Windows.
When the connection aborts with an error - most notably with an error at
the connection setup - it sometimes fails with a wrong error mes
21 matches
Mail list logo
