pgsql: Use https for gnu.org links

2020-10-13 Thread Peter Eisentraut
Use https for gnu.org links Mostly already done, but there were some stragglers. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/39b4a951003a6545268e141272e123929d0d710f Modified Files -- doc/src/sgml/installation.sgml | 2 +- src/include/c.h

pgsql: Correct error message

2020-10-13 Thread Peter Eisentraut
Correct error message Apparently copy-and-pasted from nearby. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/4e118fc33e3ca5244c11a81a71bd25cf9ed3d484 Modified Files -- src/backend/parser/parse_target.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deleti

pgsql: Paper over regression failures in infinite_recurse() on PPC64 Li

2020-10-13 Thread Tom Lane
Paper over regression failures in infinite_recurse() on PPC64 Linux. Our infinite_recurse() test to verify sane stack-overrun behavior is affected by a bug of the Linux kernel on PPC64: it will get SIGSEGV if it receives a signal when the stack depth is (a) over 1MB and (b) within a few kB of fill

pgsql: Paper over regression failures in infinite_recurse() on PPC64 Li

2020-10-13 Thread Tom Lane
Paper over regression failures in infinite_recurse() on PPC64 Linux. Our infinite_recurse() test to verify sane stack-overrun behavior is affected by a bug of the Linux kernel on PPC64: it will get SIGSEGV if it receives a signal when the stack depth is (a) over 1MB and (b) within a few kB of fill

pgsql: Paper over regression failures in infinite_recurse() on PPC64 Li

2020-10-13 Thread Tom Lane
Paper over regression failures in infinite_recurse() on PPC64 Linux. Our infinite_recurse() test to verify sane stack-overrun behavior is affected by a bug of the Linux kernel on PPC64: it will get SIGSEGV if it receives a signal when the stack depth is (a) over 1MB and (b) within a few kB of fill

Re: pgsql: postgres_fdw: reestablish new connection if cached one is detect

2020-10-13 Thread Tom Lane
Fujii Masao writes: > On 2020/10/11 9:16, Tom Lane wrote: >> Meanwhile, now that I've looked at commit 32a9c0bdf, I'm not very >> happy with it: >> >> * The control flow seems rather forced. I think it was designed >> on the assumption that reindenting the existing code is forbidden. > Isn't it

Re: pgsql: postgres_fdw: reestablish new connection if cached one is detect

2020-10-13 Thread Fujii Masao
On 2020/10/11 9:16, Tom Lane wrote: 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. So in the wake of commit fe27009cb, Many thanks for the commit fe27009cb !! this is what lorikeet is do

pgsql: Create ResultRelInfos later in InitPlan, index them by RT index.

2020-10-13 Thread Heikki Linnakangas
Create ResultRelInfos later in InitPlan, index them by RT index. Instead of allocating all the ResultRelInfos upfront in one big array, allocate them in ExecInitModifyTable(). es_result_relations is now an array of ResultRelInfo pointers, rather than an array of structs, and it is indexed by the R

pgsql: Fix the unstable output of tests added by commit 8fccf75834.

2020-10-13 Thread Amit Kapila
Fix the unstable output of tests added by commit 8fccf75834. The test cases added by that commit were trying to test the exact number of times a particular transaction has spilled. However, that number can vary if any background transaction (say by autovacuum) happens in parallel to the main trans