Re: pgsql: postgres_fdw: reestablish new connection if cached one is detect
Fujii Masao writes: >> Therefore, the easy fix is to make libpq mark the connection as >> CONNECTION_BAD even in ECONNABORTED, like we do in ECONNRESET. > Patch attached. This patch also changes errcode_for_socket_access() > so that it uses ERRCODE_CONNECTION_FAILURE rather than > ERRCODE_INTERNAL_ERROR as sqlerrorcode in ECONNABORTED case > like ECONNRESET. Is this sane? Some digging around on the net suggests that Windows will only return WSAECONNRESET for the case where it gets a TCP RST packet from the remote host. Other cases of TCP connection loss (e.g. timeout) are reported as WSAECONNABORTED. I think that our code generally only expects ECONNRESET to be reported for a lost connection. Based on this info, we clearly need to handle ECONNABORTED as being equivalent to that. I don't see any reason why we'd care to distinguish the two cases. So it seems like (a) we'd better make sure that ECONNABORTED is recognized anyplace that we're testing for ECONNRESET, and (b) that seems like a back-patchable bug fix, independently of the immediate issue. On the other hand, it seems a bit odd that we've not recognized this issue long since. Maybe the preference for ECONNABORTED only exists on a few Windows versions? I've not checked your patch in detail. regards, tom lane
pgsql: Avoid gratuitous inaccuracy in numeric width_bucket().
Avoid gratuitous inaccuracy in numeric width_bucket(). Multiply before dividing, not the reverse, so that cases that should produce exact results do produce exact results. (width_bucket_float8 got this right already.) Even when the result is inexact, this avoids making it more inexact, since only the division step introduces any imprecision. While at it, fix compute_bucket() to not uselessly repeat the sign check already done by its caller, and avoid duplicating the multiply/divide steps by adjusting variable usage. Per complaint from Martin Visser. Although this seems like a bug fix, I'm hesitant to risk changing width_bucket()'s results in stable branches, so no back-patch. Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/7538708394e7a70105a4e601e253adf80f47cca8 Modified Files -- src/backend/utils/adt/numeric.c | 31 ++- src/test/regress/expected/numeric.out | 40 +++ src/test/regress/sql/numeric.sql | 9 3 files changed, 65 insertions(+), 15 deletions(-)
pgsql: Fix numeric width_bucket() to allow its first argument to be inf
Fix numeric width_bucket() to allow its first argument to be infinite. While the calculation is not well-defined if the bounds arguments are infinite, there is a perfectly sane outcome if the test operand is infinite: it's just like any other value that's before the first bucket or after the last one. width_bucket_float8() got this right, but I was too hasty about the case when adding infinities to numerics (commit a57d312a7), so that width_bucket_numeric() just rejected it. Fix that, and sync the relevant error message strings. No back-patch needed, since infinities-in-numeric haven't shipped yet. Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/8ce423b1912b8303dbec5dc3ec78a7a725acf6c2 Modified Files -- src/backend/utils/adt/numeric.c | 5 +++-- src/test/regress/expected/numeric.out | 17 + src/test/regress/sql/numeric.sql | 7 +-- 3 files changed, 21 insertions(+), 8 deletions(-)
Re: pgsql: postgres_fdw: reestablish new connection if cached one is detect
I wrote: > I've not checked your patch in detail. Bread crumb for the archives: I started a -hackers thread about this: https://www.postgresql.org/message-id/flat/2621622.1602184554%40sss.pgh.pa.us regards, tom lane
pgsql: Fix typos in logical.c and reorderbuffer.c.
Fix typos in logical.c and reorderbuffer.c. Reviewed-by: Sawada Masahiko Discussion: https://postgr.es/m/CAA4eK1K6zTpuqf_d7wXCBjo_EF0_B6Fz3Ecp71Vq18t=wg-...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/f13f2e484172a1c865cd067796cee3568467dd51 Modified Files -- src/backend/replication/logical/logical.c | 2 +- src/backend/replication/logical/reorderbuffer.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-)
