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
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 |