pgsql: Remove extra parenthesis from comment.

Remove extra parenthesis from comment. Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/d94766a65a6012ccf9926bd154b087a0afb15068 Modified Files -- src/backend/partitioning/partbounds.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

pgsql: Remove extra parenthesis from comment.

Remove extra parenthesis from comment. Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/6a9b5a2f82cb8f7267d9e25093a643d47fd3fbb6 Modified Files -- src/backend/partitioning/partbounds.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

pgsql: Remove extra parenthesis from comment.

Remove extra parenthesis from comment. Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/eecc15c9f50dba53d18ed4cc2cbe7ffc9068 Modified Files -- src/backend/catalog/partition.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

pgsql: Remove extra parenthesis from comment.

Remove extra parenthesis from comment. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a41a1456c4a1040974939db23a81101a2f6ade6f Modified Files -- src/backend/partitioning/partbounds.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

pgsql: Add readfuncs.c support for AppendRelInfo.

Add readfuncs.c support for AppendRelInfo. This is made necessary by the fact that commit 6ef77cf46 added AppendRelInfos to plan trees. I'd concluded that this extra code was not necessary because we don't transmit that data to parallel workers ... but I forgot about -DWRITE_READ_PARSE_PLAN_TREES

pgsql: Remove unstable test case added in commit 5935917ce.

Remove unstable test case added in commit 5935917ce. The buildfarm says this produces some unexpected output with force_parallel_mode = regress. There's probably a bug underneath that, but for the moment just delete the test case to make the buildfarm green again. (I now notice that the case had

pgsql: Allow executor startup pruning to prune all child nodes.

Allow executor startup pruning to prune all child nodes. Previously, if the startup pruning logic proved that all child nodes of an Append or MergeAppend could be pruned, we still kept one, just to keep EXPLAIN from failing. The previous commit removed the ruleutils.c limitation that required thi

pgsql: Further adjust EXPLAIN's choices of table alias names.

Further adjust EXPLAIN's choices of table alias names. This patch causes EXPLAIN to always assign a separate table alias to the parent RTE of an append relation (inheritance set); before, such RTEs were ignored if not actually scanned by the plan. Since the child RTEs now always have that same al

pgsql: Emit parameter values during query bind/execute errors

Emit parameter values during query bind/execute errors This makes such log entries more useful, since the cause of the error can be dependent on the parameter values. Author: Alexey Bashtanov, Álvaro Herrera Discussion: https://postgr.es/m/[email protected] Reviewed-by:

pgsql: Doc: back-patch documentation about limitations of CHECK constra

Doc: back-patch documentation about limitations of CHECK constraints. Back-patch commits 36d442a25 and 1f66c657f into all supported branches. I'd considered doing this when putting in the latter commit, but failed to pull the trigger. Now that we've had an actual field complaint about the lack o

pgsql: Doc: back-patch documentation about limitations of CHECK constra

Doc: back-patch documentation about limitations of CHECK constraints. Back-patch commits 36d442a25 and 1f66c657f into all supported branches. I'd considered doing this when putting in the latter commit, but failed to pull the trigger. Now that we've had an actual field complaint about the lack o

pgsql: Doc: back-patch documentation about limitations of CHECK constra

Doc: back-patch documentation about limitations of CHECK constraints. Back-patch commits 36d442a25 and 1f66c657f into all supported branches. I'd considered doing this when putting in the latter commit, but failed to pull the trigger. Now that we've had an actual field complaint about the lack o

pgsql: Doc: back-patch documentation about limitations of CHECK constra

Doc: back-patch documentation about limitations of CHECK constraints. Back-patch commits 36d442a25 and 1f66c657f into all supported branches. I'd considered doing this when putting in the latter commit, but failed to pull the trigger. Now that we've had an actual field complaint about the lack o

pgsql: Doc: back-patch documentation about limitations of CHECK constra

Doc: back-patch documentation about limitations of CHECK constraints. Back-patch commits 36d442a25 and 1f66c657f into all supported branches. I'd considered doing this when putting in the latter commit, but failed to pull the trigger. Now that we've had an actual field complaint about the lack o

pgsql: Use only one thread to handle incoming signals on Windows.

Use only one thread to handle incoming signals on Windows. Since its inception, our Windows signal emulation code has worked by running a main signal thread that just watches for incoming signal requests, and then spawns a new thread to handle each such request. That design is meant for servers in

pgsql: Remove ATPrepSetStatistics

Remove ATPrepSetStatistics It was once possible to do ALTER TABLE ... SET STATISTICS on system tables without allow_sytem_table_mods. This was changed apparently by accident between PostgreSQL 9.1 and 9.2, but a code comment still claimed this was possible. Without that functionality, having a s

PostgreSQL HA & FO

Hi Everyone, Since you are committers I guess you know and can help. I am looking for the most common used, if possible with big and active community as possible Failover / High availability solution to PostgreSQL, better one that is being used in a real production and not development/testing's