pgsql: Fix documentation of pgrowlocks using "lock_type" instead of "mo

2018-10-02 Thread Michael Paquier
Fix documentation of pgrowlocks using "lock_type" instead of "modes" The example used in the documentation is outdated as well. This is an oversight from 0ac5ad5, which bumped up pgrowlocks but forgot some bits of the documentation. Reported-by: Chris Wilson Discussion: https://postgr.es/m/1538

pgsql: Fix documentation of pgrowlocks using "lock_type" instead of "mo

2018-10-02 Thread Michael Paquier
Fix documentation of pgrowlocks using "lock_type" instead of "modes" The example used in the documentation is outdated as well. This is an oversight from 0ac5ad5, which bumped up pgrowlocks but forgot some bits of the documentation. Reported-by: Chris Wilson Discussion: https://postgr.es/m/1538

pgsql: Fix documentation of pgrowlocks using "lock_type" instead of "mo

2018-10-02 Thread Michael Paquier
Fix documentation of pgrowlocks using "lock_type" instead of "modes" The example used in the documentation is outdated as well. This is an oversight from 0ac5ad5, which bumped up pgrowlocks but forgot some bits of the documentation. Reported-by: Chris Wilson Discussion: https://postgr.es/m/1538

pgsql: Fix documentation of pgrowlocks using "lock_type" instead of "mo

2018-10-02 Thread Michael Paquier
Fix documentation of pgrowlocks using "lock_type" instead of "modes" The example used in the documentation is outdated as well. This is an oversight from 0ac5ad5, which bumped up pgrowlocks but forgot some bits of the documentation. Reported-by: Chris Wilson Discussion: https://postgr.es/m/1538

pgsql: Fix documentation of pgrowlocks using "lock_type" instead of "mo

2018-10-02 Thread Michael Paquier
Fix documentation of pgrowlocks using "lock_type" instead of "modes" The example used in the documentation is outdated as well. This is an oversight from 0ac5ad5, which bumped up pgrowlocks but forgot some bits of the documentation. Reported-by: Chris Wilson Discussion: https://postgr.es/m/1538

pgsql: Fix documentation of pgrowlocks using "lock_type" instead of "mo

2018-10-02 Thread Michael Paquier
Fix documentation of pgrowlocks using "lock_type" instead of "modes" The example used in the documentation is outdated as well. This is an oversight from 0ac5ad5, which bumped up pgrowlocks but forgot some bits of the documentation. Reported-by: Chris Wilson Discussion: https://postgr.es/m/1538

pgsql: Fix documentation of pgrowlocks using "lock_type" instead of "mo

2018-10-02 Thread Michael Paquier
Fix documentation of pgrowlocks using "lock_type" instead of "modes" The example used in the documentation is outdated as well. This is an oversight from 0ac5ad5, which bumped up pgrowlocks but forgot some bits of the documentation. Reported-by: Chris Wilson Discussion: https://postgr.es/m/1538

pgsql: Fix corner-case failures in has_foo_privilege() family of functi

2018-10-02 Thread Tom Lane
Fix corner-case failures in has_foo_privilege() family of functions. The variants of these functions that take numeric inputs (OIDs or column numbers) are supposed to return NULL rather than failing on bad input; this rule reduces problems with snapshot skew when queries apply the functions to all

pgsql: Fix corner-case failures in has_foo_privilege() family of functi

2018-10-02 Thread Tom Lane
Fix corner-case failures in has_foo_privilege() family of functions. The variants of these functions that take numeric inputs (OIDs or column numbers) are supposed to return NULL rather than failing on bad input; this rule reduces problems with snapshot skew when queries apply the functions to all

pgsql: Fix corner-case failures in has_foo_privilege() family of functi

2018-10-02 Thread Tom Lane
Fix corner-case failures in has_foo_privilege() family of functions. The variants of these functions that take numeric inputs (OIDs or column numbers) are supposed to return NULL rather than failing on bad input; this rule reduces problems with snapshot skew when queries apply the functions to all

pgsql: Fix corner-case failures in has_foo_privilege() family of functi

2018-10-02 Thread Tom Lane
Fix corner-case failures in has_foo_privilege() family of functions. The variants of these functions that take numeric inputs (OIDs or column numbers) are supposed to return NULL rather than failing on bad input; this rule reduces problems with snapshot skew when queries apply the functions to all

pgsql: Fix corner-case failures in has_foo_privilege() family of functi

2018-10-02 Thread Tom Lane
Fix corner-case failures in has_foo_privilege() family of functions. The variants of these functions that take numeric inputs (OIDs or column numbers) are supposed to return NULL rather than failing on bad input; this rule reduces problems with snapshot skew when queries apply the functions to all

pgsql: Fix corner-case failures in has_foo_privilege() family of functi

2018-10-02 Thread Tom Lane
Fix corner-case failures in has_foo_privilege() family of functions. The variants of these functions that take numeric inputs (OIDs or column numbers) are supposed to return NULL rather than failing on bad input; this rule reduces problems with snapshot skew when queries apply the functions to all

pgsql: Fix corner-case failures in has_foo_privilege() family of functi

2018-10-02 Thread Tom Lane
Fix corner-case failures in has_foo_privilege() family of functions. The variants of these functions that take numeric inputs (OIDs or column numbers) are supposed to return NULL rather than failing on bad input; this rule reduces problems with snapshot skew when queries apply the functions to all

pgsql: Set snprintf.c's maximum number of NL arguments to be 31.

2018-10-02 Thread Tom Lane
Set snprintf.c's maximum number of NL arguments to be 31. Previously, we used the platform's NL_ARGMAX if any, otherwise 16. The trouble with this is that the platform value is hugely variable, ranging from the POSIX-minimum 9 to as much as 64K on recent FreeBSD. Values of more than a dozen or two

pgsql: Set snprintf.c's maximum number of NL arguments to be 31.

2018-10-02 Thread Tom Lane
Set snprintf.c's maximum number of NL arguments to be 31. Previously, we used the platform's NL_ARGMAX if any, otherwise 16. The trouble with this is that the platform value is hugely variable, ranging from the POSIX-minimum 9 to as much as 64K on recent FreeBSD. Values of more than a dozen or two

pgsql: Set snprintf.c's maximum number of NL arguments to be 31.

2018-10-02 Thread Tom Lane
Set snprintf.c's maximum number of NL arguments to be 31. Previously, we used the platform's NL_ARGMAX if any, otherwise 16. The trouble with this is that the platform value is hugely variable, ranging from the POSIX-minimum 9 to as much as 64K on recent FreeBSD. Values of more than a dozen or two

pgsql: Set snprintf.c's maximum number of NL arguments to be 31.

2018-10-02 Thread Tom Lane
Set snprintf.c's maximum number of NL arguments to be 31. Previously, we used the platform's NL_ARGMAX if any, otherwise 16. The trouble with this is that the platform value is hugely variable, ranging from the POSIX-minimum 9 to as much as 64K on recent FreeBSD. Values of more than a dozen or two

pgsql: Set snprintf.c's maximum number of NL arguments to be 31.

2018-10-02 Thread Tom Lane
Set snprintf.c's maximum number of NL arguments to be 31. Previously, we used the platform's NL_ARGMAX if any, otherwise 16. The trouble with this is that the platform value is hugely variable, ranging from the POSIX-minimum 9 to as much as 64K on recent FreeBSD. Values of more than a dozen or two

pgsql: Set snprintf.c's maximum number of NL arguments to be 31.

2018-10-02 Thread Tom Lane
Set snprintf.c's maximum number of NL arguments to be 31. Previously, we used the platform's NL_ARGMAX if any, otherwise 16. The trouble with this is that the platform value is hugely variable, ranging from the POSIX-minimum 9 to as much as 64K on recent FreeBSD. Values of more than a dozen or two

pgsql: Set snprintf.c's maximum number of NL arguments to be 31.

2018-10-02 Thread Tom Lane
Set snprintf.c's maximum number of NL arguments to be 31. Previously, we used the platform's NL_ARGMAX if any, otherwise 16. The trouble with this is that the platform value is hugely variable, ranging from the POSIX-minimum 9 to as much as 64K on recent FreeBSD. Values of more than a dozen or two

pgsql: Use slots more widely in tuple mapping code and make naming more

2018-10-02 Thread Andres Freund
Use slots more widely in tuple mapping code and make naming more consistent. It's inefficient to use a single slot for mapping between tuple descriptors for multiple tuples, as previously done when using ConvertPartitionTupleSlot(), as that means the slot's tuple descriptors change for every tuple

pgsql: Change rewriter/planner/executor/plancache to depend on RTE rell

2018-10-02 Thread Tom Lane
Change rewriter/planner/executor/plancache to depend on RTE rellockmode. Instead of recomputing the required lock levels in all these places, just use what commit fdba460a2 made the parser store in the RTE fields. This already simplifies the code measurably in these places, and follow-on changes w

pgsql: Don't build static libraries on Cygwin

2018-10-02 Thread Andrew Dunstan
Don't build static libraries on Cygwin Cygwin has been building and linking against static libraries. Although a bug this has been relatively harmless until now, when this has caused errors due to changes in the way we build certain libraries. So this patch makes things work the way we always inte

pgsql: MAXALIGN the target address where we store flattened value.

2018-10-02 Thread Amit Kapila
MAXALIGN the target address where we store flattened value. The API (EOH_flatten_into) that flattens the expanded value representation expects the target address to be maxaligned. All it's usage adhere to that principle except when serializing datums for parallel query. Fix that usage. Diagnose

pgsql: MAXALIGN the target address where we store flattened value.

2018-10-02 Thread Amit Kapila
MAXALIGN the target address where we store flattened value. The API (EOH_flatten_into) that flattens the expanded value representation expects the target address to be maxaligned. All it's usage adhere to that principle except when serializing datums for parallel query. Fix that usage. Diagnose

pgsql: MAXALIGN the target address where we store flattened value.

2018-10-02 Thread Amit Kapila
MAXALIGN the target address where we store flattened value. The API (EOH_flatten_into) that flattens the expanded value representation expects the target address to be maxaligned. All it's usage adhere to that principle except when serializing datums for parallel query. Fix that usage. Diagnose

pgsql: MAXALIGN the target address where we store flattened value.

2018-10-02 Thread Amit Kapila
MAXALIGN the target address where we store flattened value. The API (EOH_flatten_into) that flattens the expanded value representation expects the target address to be maxaligned. All it's usage adhere to that principle except when serializing datums for parallel query. Fix that usage. Diagnose