Re: Windows: Wrong error message at connection termination

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Lars Kanis <lars(at)greiz-reinsdorf(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Windows: Wrong error message at connection termination
Date: 2021-11-18 02:04:00
Message-ID: 2858709.1637201040@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thomas Munro <thomas(dot)munro(at)gmail(dot)com> 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
> isn't allowed to read any data after its write failed, which is a
> known source of error messages being eaten.

Yeah. After re-reading that thread, I'm a bit confused about how
to square the results we got then with Lars' report. The Windows
documentation he pointed to does claim that the default behavior if you
issue closesocket() is to do a "graceful close in the background", which
one would think means allowing sent data to be received. That's not what
we saw. It's possible that we would get different results if we re-tested
with a scenario where the client doesn't attempt to send data after the
server-side close; but I'm not sure how much it's worth to improve that
case if the other case still fails hard. In any case, our previous
results definitely show that issuing an explicit close() is no panacea.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2021-11-18 02:23:17 Re: wait event and archive_command
Previous Message Peter Smith 2021-11-18 01:33:42 Re: row filtering for logical replication