pgsql: Improve documentation of data_sync_retry

Improve documentation of data_sync_retry Reflecting an updated parameter value requires a server restart, which was not mentioned in the documentation and in postgresql.conf.sample. Reported-by: Thomas Poty Discussion: https://postgr.es/m/[email protected] Branch -- REL9_

pgsql: Improve documentation of data_sync_retry

Improve documentation of data_sync_retry Reflecting an updated parameter value requires a server restart, which was not mentioned in the documentation and in postgresql.conf.sample. Reported-by: Thomas Poty Discussion: https://postgr.es/m/[email protected] Branch -- REL9_

pgsql: Improve documentation of data_sync_retry

Improve documentation of data_sync_retry Reflecting an updated parameter value requires a server restart, which was not mentioned in the documentation and in postgresql.conf.sample. Reported-by: Thomas Poty Discussion: https://postgr.es/m/[email protected] Branch -- REL_1

pgsql: Improve documentation of data_sync_retry

Improve documentation of data_sync_retry Reflecting an updated parameter value requires a server restart, which was not mentioned in the documentation and in postgresql.conf.sample. Reported-by: Thomas Poty Discussion: https://postgr.es/m/[email protected] Branch -- REL9_

pgsql: Improve documentation of data_sync_retry

Improve documentation of data_sync_retry Reflecting an updated parameter value requires a server restart, which was not mentioned in the documentation and in postgresql.conf.sample. Reported-by: Thomas Poty Discussion: https://postgr.es/m/[email protected] Branch -- REL_1

pgsql: Improve documentation of data_sync_retry

Improve documentation of data_sync_retry Reflecting an updated parameter value requires a server restart, which was not mentioned in the documentation and in postgresql.conf.sample. Reported-by: Thomas Poty Discussion: https://postgr.es/m/[email protected] Branch -- maste

pgsql: Fix SCRAM authentication via SSL when mixing versions of OpenSSL

Fix SCRAM authentication via SSL when mixing versions of OpenSSL When using a libpq client linked with OpenSSL 1.0.1 or older to connect to a backend linked with OpenSSL 1.0.2 or newer, the server would send SCRAM-SHA-256-PLUS and SCRAM-SHA-256 as valid mechanisms for the SASL exchange, and the cl

pgsql: Fix SCRAM authentication via SSL when mixing versions of OpenSSL

Fix SCRAM authentication via SSL when mixing versions of OpenSSL When using a libpq client linked with OpenSSL 1.0.1 or older to connect to a backend linked with OpenSSL 1.0.2 or newer, the server would send SCRAM-SHA-256-PLUS and SCRAM-SHA-256 as valid mechanisms for the SASL exchange, and the cl

pgsql: Remove unused macro

Remove unused macro It has never been used as long as hstore has been in the tree. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/da35d14806249c4619b2b5efda061211768a27ce Modified Files -- contrib/hstore/hstore_gist.c | 3 --- 1 file changed, 3 deletion

Re: pgsql: Use slots in trigger infrastructure, except for the actual invoc

On 2019-02-27 12:59:16 -0500, Andrew Dunstan wrote: > > On 2/27/19 1:22 AM, Andres Freund wrote: > > Hi, > > > > On 2019-02-27 04:41:28 +, Andres Freund wrote: > >> Use slots in trigger infrastructure, except for the actual invocation. > > Andrew, I see that this broke crake's redis_fdw check.

Re: pgsql: Use slots in trigger infrastructure, except for the actual invoc

On 2/27/19 1:22 AM, Andres Freund wrote: > Hi, > > On 2019-02-27 04:41:28 +, Andres Freund wrote: >> Use slots in trigger infrastructure, except for the actual invocation. > Andrew, I see that this broke crake's redis_fdw check. I see it actually > fails with an error, rather than fail to bui

Re: pgsql: Use slots in trigger infrastructure, except for the actual invoc

Andres Freund writes: > Hm, yea, I can see why a compiler, especially without doing more > expensive control flow analysis, would get this wrong. Easier to > understand if we NULL initialize rInfo, not just rel, too. Pushed. All quiet now; thanks. regards, tom lane

Re: pgsql: Use slots in trigger infrastructure, except for the actual invoc

Hi, On 2019-02-27 11:35:18 -0500, Tom Lane wrote: > Andres Freund writes: > > Use slots in trigger infrastructure, except for the actual invocation. > > I believe it's this commit that is resulting in my compiler bleating > about > > trigger.c: In function 'afterTriggerInvokeEvents': > trigger.

pgsql: Initialize variable to silence compiler warning.

Initialize variable to silence compiler warning. After ff11e7f4b9ae Tom's compiler warns about accessing a potentially uninitialized rInfo. That's not actually possible, but it's understandable the compiler would get this wrong. NULL initialize too. Reported-By: Tom Lane Discussion: https://postg

Re: pgsql: Use slots in trigger infrastructure, except for the actual invoc

Andres Freund writes: > Use slots in trigger infrastructure, except for the actual invocation. I believe it's this commit that is resulting in my compiler bleating about trigger.c: In function 'afterTriggerInvokeEvents': trigger.c:4493: warning: 'rInfo' may be used uninitialized in this function

pgsql: Set fallback_application_name for a walreceiver to cluster_name

Set fallback_application_name for a walreceiver to cluster_name By default, the fallback_application_name for a physical walreceiver is "walreceiver". This means that multiple standbys cannot be distinguished easily on a primary, for example in pg_stat_activity or synchronous_standby_names. If c

pgsql: Set cluster_name for PostgresNode.pm instances

Set cluster_name for PostgresNode.pm instances This can help identifying test instances more easily at run time, and it also provides some minimal test coverage for the cluster_name feature. Reviewed-by: Euler Taveira Discussion: https://www.postgresql.org/message-id/flat/1257eaee-4874-e791-e83