pgsql: Reject empty names and recursion in config-file include directiv

2019-08-27 Thread Tom Lane
Reject empty names and recursion in config-file include directives. An empty file name or subdirectory name leads join_path_components() to just produce the parent directory name, which leads to weird failures or recursive inclusions. Let's throw a specific error for that. It takes only slightly

pgsql: Reject empty names and recursion in config-file include directiv

2019-08-27 Thread Tom Lane
Reject empty names and recursion in config-file include directives. An empty file name or subdirectory name leads join_path_components() to just produce the parent directory name, which leads to weird failures or recursive inclusions. Let's throw a specific error for that. It takes only slightly

pgsql: Reject empty names and recursion in config-file include directiv

2019-08-27 Thread Tom Lane
Reject empty names and recursion in config-file include directives. An empty file name or subdirectory name leads join_path_components() to just produce the parent directory name, which leads to weird failures or recursive inclusions. Let's throw a specific error for that. It takes only slightly

pgsql: Reject empty names and recursion in config-file include directiv

2019-08-27 Thread Tom Lane
Reject empty names and recursion in config-file include directives. An empty file name or subdirectory name leads join_path_components() to just produce the parent directory name, which leads to weird failures or recursive inclusions. Let's throw a specific error for that. It takes only slightly

pgsql: Reject empty names and recursion in config-file include directiv

2019-08-27 Thread Tom Lane
Reject empty names and recursion in config-file include directives. An empty file name or subdirectory name leads join_path_components() to just produce the parent directory name, which leads to weird failures or recursive inclusions. Let's throw a specific error for that. It takes only slightly

pgsql: Reject empty names and recursion in config-file include directiv

2019-08-27 Thread Tom Lane
Reject empty names and recursion in config-file include directives. An empty file name or subdirectory name leads join_path_components() to just produce the parent directory name, which leads to weird failures or recursive inclusions. Let's throw a specific error for that. It takes only slightly

pgsql: Add missing newline in help output.

2019-08-27 Thread Tom Lane
Add missing newline in help output. Daniel Gustafsson Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/d4b2425441b7ab298300142d64bb8020d38b290f Modified Files -- src/bin/pg_up

pgsql: Doc: clarify behavior of standard aggregates for null inputs.

2019-08-27 Thread Tom Lane
Doc: clarify behavior of standard aggregates for null inputs. Section 4.2.7 says that unless otherwise specified, built-in aggregates ignore rows in which any input is null. This is not true of the JSON aggregates, but it wasn't documented. Fix that. Of the other entries in table 9.55, some were

pgsql: Doc: clarify behavior of standard aggregates for null inputs.

2019-08-27 Thread Tom Lane
Doc: clarify behavior of standard aggregates for null inputs. Section 4.2.7 says that unless otherwise specified, built-in aggregates ignore rows in which any input is null. This is not true of the JSON aggregates, but it wasn't documented. Fix that. Of the other entries in table 9.55, some were

pgsql: Doc: clarify behavior of standard aggregates for null inputs.

2019-08-27 Thread Tom Lane
Doc: clarify behavior of standard aggregates for null inputs. Section 4.2.7 says that unless otherwise specified, built-in aggregates ignore rows in which any input is null. This is not true of the JSON aggregates, but it wasn't documented. Fix that. Of the other entries in table 9.55, some were

pgsql: Doc: clarify behavior of standard aggregates for null inputs.

2019-08-27 Thread Tom Lane
Doc: clarify behavior of standard aggregates for null inputs. Section 4.2.7 says that unless otherwise specified, built-in aggregates ignore rows in which any input is null. This is not true of the JSON aggregates, but it wasn't documented. Fix that. Of the other entries in table 9.55, some were

pgsql: Doc: clarify behavior of standard aggregates for null inputs.

2019-08-27 Thread Tom Lane
Doc: clarify behavior of standard aggregates for null inputs. Section 4.2.7 says that unless otherwise specified, built-in aggregates ignore rows in which any input is null. This is not true of the JSON aggregates, but it wasn't documented. Fix that. Of the other entries in table 9.55, some were

pgsql: Doc: clarify behavior of standard aggregates for null inputs.

2019-08-27 Thread Tom Lane
Doc: clarify behavior of standard aggregates for null inputs. Section 4.2.7 says that unless otherwise specified, built-in aggregates ignore rows in which any input is null. This is not true of the JSON aggregates, but it wasn't documented. Fix that. Of the other entries in table 9.55, some were

pgsql: Doc: clarify behavior of standard aggregates for null inputs.

2019-08-27 Thread Tom Lane
Doc: clarify behavior of standard aggregates for null inputs. Section 4.2.7 says that unless otherwise specified, built-in aggregates ignore rows in which any input is null. This is not true of the JSON aggregates, but it wasn't documented. Fix that. Of the other entries in table 9.55, some were

pgsql: Remove obsolete nbtree page deletion comment.

2019-08-27 Thread Peter Geoghegan
Remove obsolete nbtree page deletion comment. Commit efada2b8e92, which made the nbtree page deletion algorithm more robust, removed the concept of a half-dead internal page. Remove a comment about half dead parent pages that was overlooked. Branch -- master Details --- https://git.post

pgsql: Improve what pg_strsignal prints if we haven't got strsignal(3).

2019-08-27 Thread Tom Lane
Improve what pg_strsignal prints if we haven't got strsignal(3). Turns out that returning "unrecognized signal" is confusing. Make it explicit that the platform lacks any support for signal names. (At least of the machines in the buildfarm, only HPUX lacks it.) Back-patch to v12 where we invented

pgsql: Improve what pg_strsignal prints if we haven't got strsignal(3).

2019-08-27 Thread Tom Lane
Improve what pg_strsignal prints if we haven't got strsignal(3). Turns out that returning "unrecognized signal" is confusing. Make it explicit that the platform lacks any support for signal names. (At least of the machines in the buildfarm, only HPUX lacks it.) Back-patch to v12 where we invented

pgsql: Doc: improve documentation of pg_signal_backend default role.

2019-08-27 Thread Tom Lane
Doc: improve documentation of pg_signal_backend default role. Give it an explanatory para like the other default roles have. Don't imply that it can send any signal whatever. In passing, reorder the table entries and explanatory paras for the default roles into some semblance of consistency. Ian

pgsql: Doc: improve documentation of pg_signal_backend default role.

2019-08-27 Thread Tom Lane
Doc: improve documentation of pg_signal_backend default role. Give it an explanatory para like the other default roles have. Don't imply that it can send any signal whatever. In passing, reorder the table entries and explanatory paras for the default roles into some semblance of consistency. Ian

pgsql: Doc: improve documentation of pg_signal_backend default role.

2019-08-27 Thread Tom Lane
Doc: improve documentation of pg_signal_backend default role. Give it an explanatory para like the other default roles have. Don't imply that it can send any signal whatever. In passing, reorder the table entries and explanatory paras for the default roles into some semblance of consistency. Ian

pgsql: Doc: improve documentation of pg_signal_backend default role.

2019-08-27 Thread Tom Lane
Doc: improve documentation of pg_signal_backend default role. Give it an explanatory para like the other default roles have. Don't imply that it can send any signal whatever. In passing, reorder the table entries and explanatory paras for the default roles into some semblance of consistency. Ian

pgsql: Set application_name per-test in isolation and ecpg tests.

2019-08-27 Thread Tom Lane
Set application_name per-test in isolation and ecpg tests. Commit a4327296d taught pg_regress proper to do this, but missed the opportunity to do likewise in the isolationtester and ecpg variants of pg_regress. Seems like this might be helpful for tracking down issues exposed by those tests. Bra

Re: pgsql: Fix 007_sync_rep.pl to notice failures in ALTER SYSTEM SET.

2019-08-27 Thread Michael Paquier
On Mon, Aug 26, 2019 at 09:03:08PM +, Tom Lane wrote: > Fix 007_sync_rep.pl to notice failures in ALTER SYSTEM SET. > > If a test case tried to set an invalid value of synchronous_standby_names, > the test script didn't detect that, which seems like a bad idea. > Noticed while testing a propos

pgsql: Disable timeouts when running pg_rewind with online source clust

2019-08-27 Thread Michael Paquier
Disable timeouts when running pg_rewind with online source cluster In this case, the transfer uses a libpq connection, which is subject to the timeout parameters set at system level, and this can make the rewind operation suddenly canceled which is not good for automation. One workaround to such

pgsql: Disable timeouts when running pg_rewind with online source clust

2019-08-27 Thread Michael Paquier
Disable timeouts when running pg_rewind with online source cluster In this case, the transfer uses a libpq connection, which is subject to the timeout parameters set at system level, and this can make the rewind operation suddenly canceled which is not good for automation. One workaround to such

pgsql: Disable timeouts when running pg_rewind with online source clust

2019-08-27 Thread Michael Paquier
Disable timeouts when running pg_rewind with online source cluster In this case, the transfer uses a libpq connection, which is subject to the timeout parameters set at system level, and this can make the rewind operation suddenly canceled which is not good for automation. One workaround to such

pgsql: Disable timeouts when running pg_rewind with online source clust

2019-08-27 Thread Michael Paquier
Disable timeouts when running pg_rewind with online source cluster In this case, the transfer uses a libpq connection, which is subject to the timeout parameters set at system level, and this can make the rewind operation suddenly canceled which is not good for automation. One workaround to such

pgsql: Disable timeouts when running pg_rewind with online source clust

2019-08-27 Thread Michael Paquier
Disable timeouts when running pg_rewind with online source cluster In this case, the transfer uses a libpq connection, which is subject to the timeout parameters set at system level, and this can make the rewind operation suddenly canceled which is not good for automation. One workaround to such

pgsql: Disable timeouts when running pg_rewind with online source clust

2019-08-27 Thread Michael Paquier
Disable timeouts when running pg_rewind with online source cluster In this case, the transfer uses a libpq connection, which is subject to the timeout parameters set at system level, and this can make the rewind operation suddenly canceled which is not good for automation. One workaround to such

pgsql: Improve coverage of utils/float.h

2019-08-27 Thread Michael Paquier
Improve coverage of utils/float.h check_float4_val() checks after underflow and overflow of values converted from float8 to float4, but there has never been any regression tests for that. This brings the coverage of float.h to 100%. Author: Movead Li Discussion: https://postgr.es/m/2019082217463

Re: pgsql: Fix 007_sync_rep.pl to notice failures in ALTER SYSTEM SET.

2019-08-27 Thread Tom Lane
Michael Paquier writes: > On Mon, Aug 26, 2019 at 09:03:08PM +, Tom Lane wrote: >> Fix 007_sync_rep.pl to notice failures in ALTER SYSTEM SET. > Just for the note. I think that this needs a closer lookup and I am > afraid that there are more issues like this one. Yeah, it might be a good id

Re: pgsql: Fix 007_sync_rep.pl to notice failures in ALTER SYSTEM SET.

2019-08-27 Thread Michael Paquier
On Tue, Aug 27, 2019 at 11:38:28PM -0400, Tom Lane wrote: > Yeah, it might be a good idea to make a sweep to see what other tests > should be using safe_psql. I found more of these while browsing all the tests, so I am just going to start a new thread with a patch. > Or, more radically, we could