agora inbox for [email protected]
help / color / mirror / Atom feedRe: Partition-wise join for join between (declaratively) partitioned tables
277+ messages / 9 participants
[nested] [flat]
* Re: Partition-wise join for join between (declaratively) partitioned tables
@ 2017-03-01 08:56 Ashutosh Bapat <[email protected]>
2017-03-02 04:52 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-09 01:14 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
0 siblings, 2 replies; 277+ messages in thread
From: Ashutosh Bapat @ 2017-03-01 08:56 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: Rajkumar Raghuwanshi <[email protected]>; pgsql-hackers
>
> 2. If the PartitionJoinPath emerges as the best path, we create paths
> for each of the remaining child-joins. Then we collect paths with
> properties same as the given PartitionJoinPath, one from each
> child-join. These paths are converted into plans and a Merge/Append
> plan is created combing these plans. The paths and plans for
> child-join are created in a temporary memory context. The final plan
> for each child-join is copied into planner's context and the temporary
> memory context is reset.
>
Robert and I discussed this in more detail. Path creation code may
allocate objects other than paths. postgres_fdw, for example,
allocates character array to hold the name of relation being
pushed-down. When the temporary context gets zapped after creating
paths for a given child-join, those other objects also gets thrown
away. Attached patch has implemented the idea that came out of the
discussion.
We create a memory context for holding paths at the time of creating
PlannerGlobal and save it in PlannerGlobal. The patch introduces a new
macro makePathNode() which allocates the memory for given type of path
from this context. Every create_*_path function has been changed to
use this macro instead of makeNode(). In standard_planner(), at the
end of planning we destroy the memory context freeing all the paths
allocated. While creating a plan node, planner copies everything
required by the plan from the path, so the path is not needed any
more. So, freeing corresponding memory should not have any adverse
effects.
Most of the create_*_path() functions accept root as an argument, thus
the temporary path context is available through root->glob everywhere.
An exception is create_append_path() which does not accept root as an
argument. The patch changes create_append_path() and its callers like
set_dummy_rel_pathlist(), mark_dummy_rel() to accept root as an
argument. Ideally paths are not required after creating plan, so we
should be
able to free the context right after the call to create_plan(). But we
need dummy paths while creating flat rtable in
set_plan_references()->add_rtes_to_flat_rtable(). We used to So free
the path context at the end of planning cycle. Now that we are
allocating all the paths in a different memory context, it doesn't
make sense to switch context in mark_dummy_rel().
0001 patch implements the idea described above.
0002 patch adds instrumentation to measure memory consumed in
standard_planner() call.
0003 patch adds a GUC zap_paths to enable/disable destroying path context.
The last two patches are for testing only.
Attached also find the SQL script and its output showing the memory
saved. For a 5 way self-join of pg_class, the total memory consumed in
standard_planner() is 760K without patch and with patch it comes down
to 713K, saving 47K memory otherwise occupied by paths. It looks like
something useful even without partition-wise joins.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Attachments:
[application/octet-stream] 0001-Free-up-memory-consumed-by-the-paths.patch (27.0K, ../../CAFjFpRfTHJ5AHd0Ydb+DAsybhcT+2ViiuzKy+yKtOZArQ4eN+g@mail.gmail.com/2-0001-Free-up-memory-consumed-by-the-paths.patch)
download | inline diff:
From d62d4a40dc52ab05416446d19eaf53125d33aa4b Mon Sep 17 00:00:00 2001
From: Ashutosh Bapat <[email protected]>
Date: Wed, 1 Mar 2017 11:07:28 +0530
Subject: [PATCH 1/3] Free up memory consumed by the paths.
Optimizer creates many paths while planning the query. Only one path
tree gets converted to the plan. The memory consumed by paths even
after the plan is created. For a simple query, it means that the
memory remains occupied till the end of the execution. Since plan node
copies the relevant information from the corresponding path, paths are
not needed after plan is created. We can free up that memory.
While creating global planner structure (PlannerGlob) we allocated a
separate memory context for creating paths. Every create_*_path()
function allocates path node in this context. The context is freed at
the end of planning cycle after creating PlannedStmt.
Ideally paths are not required after creating plan, so we should be
able to free the context right after the call to create_plan(). But we
need dummy paths while creating flat rtable in
set_plan_references()->add_rtes_to_flat_rtable(). There might be other
corner cases where we need paths. So free the path context at the end
of planning cycle.
---
src/backend/optimizer/path/allpaths.c | 25 ++++-----
src/backend/optimizer/path/joinpath.c | 2 +-
src/backend/optimizer/path/joinrels.c | 22 ++++----
src/backend/optimizer/plan/planner.c | 16 +++++-
src/backend/optimizer/prep/prepunion.c | 4 +-
src/backend/optimizer/util/pathnode.c | 91 +++++++++++++++++++-------------
src/include/nodes/relation.h | 2 +
src/include/optimizer/pathnode.h | 10 ++--
src/include/optimizer/paths.h | 2 +-
9 files changed, 104 insertions(+), 70 deletions(-)
diff --git a/src/backend/optimizer/path/allpaths.c b/src/backend/optimizer/path/allpaths.c
index 633b5c1..e22817e 100644
--- a/src/backend/optimizer/path/allpaths.c
+++ b/src/backend/optimizer/path/allpaths.c
@@ -325,7 +325,7 @@ set_rel_size(PlannerInfo *root, RelOptInfo *rel,
* we don't have a convention for marking a rel as dummy except by
* assigning a dummy path to it.
*/
- set_dummy_rel_pathlist(rel);
+ set_dummy_rel_pathlist(root, rel);
}
else if (rte->inh)
{
@@ -769,7 +769,7 @@ set_tablesample_rel_pathlist(PlannerInfo *root, RelOptInfo *rel, RangeTblEntry *
bms_membership(root->all_baserels) != BMS_SINGLETON) &&
!(GetTsmRoutine(rte->tablesample->tsmhandler)->repeatable_across_scans))
{
- path = (Path *) create_material_path(rel, path);
+ path = (Path *) create_material_path(root, rel, path);
}
add_path(rel, path);
@@ -993,7 +993,7 @@ set_append_rel_size(PlannerInfo *root, RelOptInfo *rel,
* Some restriction clause reduced to constant FALSE or NULL after
* substitution, so this child need not be scanned.
*/
- set_dummy_rel_pathlist(childrel);
+ set_dummy_rel_pathlist(root, childrel);
continue;
}
@@ -1003,7 +1003,7 @@ set_append_rel_size(PlannerInfo *root, RelOptInfo *rel,
* This child need not be scanned, so we can omit it from the
* appendrel.
*/
- set_dummy_rel_pathlist(childrel);
+ set_dummy_rel_pathlist(root, childrel);
continue;
}
@@ -1153,7 +1153,7 @@ set_append_rel_size(PlannerInfo *root, RelOptInfo *rel,
* appendrel dummy. We must do this in this phase so that the rel's
* dummy-ness is visible when we generate paths for other rels.
*/
- set_dummy_rel_pathlist(rel);
+ set_dummy_rel_pathlist(root, rel);
}
pfree(parent_attrsizes);
@@ -1314,7 +1314,8 @@ set_append_rel_pathlist(PlannerInfo *root, RelOptInfo *rel,
* if we have zero or one live subpath due to constraint exclusion.)
*/
if (subpaths_valid)
- add_path(rel, (Path *) create_append_path(rel, subpaths, NULL, 0));
+ add_path(rel, (Path *) create_append_path(root, rel, subpaths, NULL,
+ 0));
/*
* Consider an append of partial unordered, unparameterized partial paths.
@@ -1340,7 +1341,7 @@ set_append_rel_pathlist(PlannerInfo *root, RelOptInfo *rel,
Assert(parallel_workers > 0);
/* Generate a partial append path. */
- appendpath = create_append_path(rel, partial_subpaths, NULL,
+ appendpath = create_append_path(root, rel, partial_subpaths, NULL,
parallel_workers);
add_partial_path(rel, (Path *) appendpath);
}
@@ -1392,8 +1393,8 @@ set_append_rel_pathlist(PlannerInfo *root, RelOptInfo *rel,
}
if (subpaths_valid)
- add_path(rel, (Path *)
- create_append_path(rel, subpaths, required_outer, 0));
+ add_path(rel, (Path *) create_append_path(root, rel, subpaths,
+ required_outer, 0));
}
}
@@ -1613,7 +1614,7 @@ accumulate_append_subpath(List *subpaths, Path *path)
* This is exported because inheritance_planner() has need for it.
*/
void
-set_dummy_rel_pathlist(RelOptInfo *rel)
+set_dummy_rel_pathlist(PlannerInfo *root, RelOptInfo *rel)
{
/* Set dummy size estimates --- we leave attr_widths[] as zeroes */
rel->rows = 0;
@@ -1623,7 +1624,7 @@ set_dummy_rel_pathlist(RelOptInfo *rel)
rel->pathlist = NIL;
rel->partial_pathlist = NIL;
- add_path(rel, (Path *) create_append_path(rel, NIL, NULL, 0));
+ add_path(rel, (Path *) create_append_path(root, rel, NIL, NULL, 0));
/*
* We set the cheapest path immediately, to ensure that IS_DUMMY_REL()
@@ -1808,7 +1809,7 @@ set_subquery_pathlist(PlannerInfo *root, RelOptInfo *rel,
if (IS_DUMMY_REL(sub_final_rel))
{
- set_dummy_rel_pathlist(rel);
+ set_dummy_rel_pathlist(root, rel);
return;
}
diff --git a/src/backend/optimizer/path/joinpath.c b/src/backend/optimizer/path/joinpath.c
index 2897245..2a0f6d9 100644
--- a/src/backend/optimizer/path/joinpath.c
+++ b/src/backend/optimizer/path/joinpath.c
@@ -1124,7 +1124,7 @@ match_unsorted_outer(PlannerInfo *root,
if (enable_material && inner_cheapest_total != NULL &&
!ExecMaterializesOutput(inner_cheapest_total->pathtype))
matpath = (Path *)
- create_material_path(innerrel, inner_cheapest_total);
+ create_material_path(root, innerrel, inner_cheapest_total);
}
foreach(lc1, outerrel->pathlist)
diff --git a/src/backend/optimizer/path/joinrels.c b/src/backend/optimizer/path/joinrels.c
index 0d00683..ff493b3 100644
--- a/src/backend/optimizer/path/joinrels.c
+++ b/src/backend/optimizer/path/joinrels.c
@@ -29,7 +29,7 @@ static void make_rels_by_clauseless_joins(PlannerInfo *root,
static bool has_join_restriction(PlannerInfo *root, RelOptInfo *rel);
static bool has_legal_joinclause(PlannerInfo *root, RelOptInfo *rel);
static bool is_dummy_rel(RelOptInfo *rel);
-static void mark_dummy_rel(RelOptInfo *rel);
+static void mark_dummy_rel(PlannerInfo *root, RelOptInfo *rel);
static bool restriction_is_constant_false(List *restrictlist,
bool only_pushed_down);
@@ -748,7 +748,7 @@ make_join_rel(PlannerInfo *root, RelOptInfo *rel1, RelOptInfo *rel2)
if (is_dummy_rel(rel1) || is_dummy_rel(rel2) ||
restriction_is_constant_false(restrictlist, false))
{
- mark_dummy_rel(joinrel);
+ mark_dummy_rel(root, joinrel);
break;
}
add_paths_to_joinrel(root, joinrel, rel1, rel2,
@@ -762,12 +762,12 @@ make_join_rel(PlannerInfo *root, RelOptInfo *rel1, RelOptInfo *rel2)
if (is_dummy_rel(rel1) ||
restriction_is_constant_false(restrictlist, true))
{
- mark_dummy_rel(joinrel);
+ mark_dummy_rel(root, joinrel);
break;
}
if (restriction_is_constant_false(restrictlist, false) &&
bms_is_subset(rel2->relids, sjinfo->syn_righthand))
- mark_dummy_rel(rel2);
+ mark_dummy_rel(root, rel2);
add_paths_to_joinrel(root, joinrel, rel1, rel2,
JOIN_LEFT, sjinfo,
restrictlist);
@@ -779,7 +779,7 @@ make_join_rel(PlannerInfo *root, RelOptInfo *rel1, RelOptInfo *rel2)
if ((is_dummy_rel(rel1) && is_dummy_rel(rel2)) ||
restriction_is_constant_false(restrictlist, true))
{
- mark_dummy_rel(joinrel);
+ mark_dummy_rel(root, joinrel);
break;
}
add_paths_to_joinrel(root, joinrel, rel1, rel2,
@@ -815,7 +815,7 @@ make_join_rel(PlannerInfo *root, RelOptInfo *rel1, RelOptInfo *rel2)
if (is_dummy_rel(rel1) || is_dummy_rel(rel2) ||
restriction_is_constant_false(restrictlist, false))
{
- mark_dummy_rel(joinrel);
+ mark_dummy_rel(root, joinrel);
break;
}
add_paths_to_joinrel(root, joinrel, rel1, rel2,
@@ -838,7 +838,7 @@ make_join_rel(PlannerInfo *root, RelOptInfo *rel1, RelOptInfo *rel2)
if (is_dummy_rel(rel1) || is_dummy_rel(rel2) ||
restriction_is_constant_false(restrictlist, false))
{
- mark_dummy_rel(joinrel);
+ mark_dummy_rel(root, joinrel);
break;
}
add_paths_to_joinrel(root, joinrel, rel1, rel2,
@@ -853,12 +853,12 @@ make_join_rel(PlannerInfo *root, RelOptInfo *rel1, RelOptInfo *rel2)
if (is_dummy_rel(rel1) ||
restriction_is_constant_false(restrictlist, true))
{
- mark_dummy_rel(joinrel);
+ mark_dummy_rel(root, joinrel);
break;
}
if (restriction_is_constant_false(restrictlist, false) &&
bms_is_subset(rel2->relids, sjinfo->syn_righthand))
- mark_dummy_rel(rel2);
+ mark_dummy_rel(root, rel2);
add_paths_to_joinrel(root, joinrel, rel1, rel2,
JOIN_ANTI, sjinfo,
restrictlist);
@@ -1178,7 +1178,7 @@ is_dummy_rel(RelOptInfo *rel)
* context the given RelOptInfo is in.
*/
static void
-mark_dummy_rel(RelOptInfo *rel)
+mark_dummy_rel(PlannerInfo *root, RelOptInfo *rel)
{
MemoryContext oldcontext;
@@ -1197,7 +1197,7 @@ mark_dummy_rel(RelOptInfo *rel)
rel->partial_pathlist = NIL;
/* Set up the dummy path */
- add_path(rel, (Path *) create_append_path(rel, NIL, NULL, 0));
+ add_path(rel, (Path *) create_append_path(root, rel, NIL, NULL, 0));
/* Set or update cheapest_total_path and related fields */
set_cheapest(rel);
diff --git a/src/backend/optimizer/plan/planner.c b/src/backend/optimizer/plan/planner.c
index ca0ae78..b74e887 100644
--- a/src/backend/optimizer/plan/planner.c
+++ b/src/backend/optimizer/plan/planner.c
@@ -54,6 +54,7 @@
#include "utils/rel.h"
#include "utils/selfuncs.h"
#include "utils/lsyscache.h"
+#include "utils/memutils.h"
#include "utils/syscache.h"
@@ -218,6 +219,9 @@ standard_planner(Query *parse, int cursorOptions, ParamListInfo boundParams)
glob->lastPlanNodeId = 0;
glob->transientPlan = false;
glob->dependsOnRole = false;
+ glob->path_cxt = AllocSetContextCreate(CurrentMemoryContext,
+ "Path creation temporary context",
+ ALLOCSET_DEFAULT_SIZES);
/*
* Assess whether it's feasible to use parallel mode for this query. We
@@ -414,6 +418,13 @@ standard_planner(Query *parse, int cursorOptions, ParamListInfo boundParams)
result->stmt_location = parse->stmt_location;
result->stmt_len = parse->stmt_len;
+ /*
+ * We do not need paths any more, blow those away.
+ * TODO: probably we should also set the pathlists to NIL.
+ */
+ MemoryContextResetAndDeleteChildren(glob->path_cxt);
+ glob->path_cxt = NULL;
+
return result;
}
@@ -1302,7 +1313,7 @@ inheritance_planner(PlannerInfo *root)
*/
if (subpaths == NIL)
{
- set_dummy_rel_pathlist(final_rel);
+ set_dummy_rel_pathlist(root, final_rel);
return;
}
@@ -3334,7 +3345,7 @@ create_grouping_paths(PlannerInfo *root,
paths = lappend(paths, path);
}
path = (Path *)
- create_append_path(grouped_rel,
+ create_append_path(root, grouped_rel,
paths,
NULL,
0);
@@ -5261,6 +5272,7 @@ plan_cluster_use_sort(Oid tableOid, Oid indexOid)
query->commandType = CMD_SELECT;
glob = makeNode(PlannerGlobal);
+ glob->path_cxt = CurrentMemoryContext;
root = makeNode(PlannerInfo);
root->parse = query;
diff --git a/src/backend/optimizer/prep/prepunion.c b/src/backend/optimizer/prep/prepunion.c
index 1389db1..492f8df 100644
--- a/src/backend/optimizer/prep/prepunion.c
+++ b/src/backend/optimizer/prep/prepunion.c
@@ -566,7 +566,7 @@ generate_union_path(SetOperationStmt *op, PlannerInfo *root,
/*
* Append the child results together.
*/
- path = (Path *) create_append_path(result_rel, pathlist, NULL, 0);
+ path = (Path *) create_append_path(root, result_rel, pathlist, NULL, 0);
/* We have to manually jam the right tlist into the path; ick */
path->pathtarget = create_pathtarget(root, tlist);
@@ -678,7 +678,7 @@ generate_nonunion_path(SetOperationStmt *op, PlannerInfo *root,
/*
* Append the child results together.
*/
- path = (Path *) create_append_path(result_rel, pathlist, NULL, 0);
+ path = (Path *) create_append_path(root, result_rel, pathlist, NULL, 0);
/* We have to manually jam the right tlist into the path; ick */
path->pathtarget = create_pathtarget(root, tlist);
diff --git a/src/backend/optimizer/util/pathnode.c b/src/backend/optimizer/util/pathnode.c
index 3248296..b91b25e 100644
--- a/src/backend/optimizer/util/pathnode.c
+++ b/src/backend/optimizer/util/pathnode.c
@@ -928,6 +928,18 @@ add_partial_path_precheck(RelOptInfo *parent_rel, Cost total_cost,
/*****************************************************************************
* PATH NODE CREATION ROUTINES
*****************************************************************************/
+#define makePathNode(root, _type_) ((_type_ *) newPath((root), sizeof(_type_),T_##_type_))
+
+static Path *
+newPath(PlannerInfo *root, size_t size, NodeTag tag)
+{
+ Path *result;
+
+ Assert(sizeof(Path) <= size);
+ result = MemoryContextAllocZero(root->glob->path_cxt, size);
+ result->type = tag;
+ return result;
+}
/*
* create_seqscan_path
@@ -938,7 +950,7 @@ Path *
create_seqscan_path(PlannerInfo *root, RelOptInfo *rel,
Relids required_outer, int parallel_workers)
{
- Path *pathnode = makeNode(Path);
+ Path *pathnode = makePathNode(root, Path);
pathnode->pathtype = T_SeqScan;
pathnode->parent = rel;
@@ -962,7 +974,7 @@ create_seqscan_path(PlannerInfo *root, RelOptInfo *rel,
Path *
create_samplescan_path(PlannerInfo *root, RelOptInfo *rel, Relids required_outer)
{
- Path *pathnode = makeNode(Path);
+ Path *pathnode = makePathNode(root, Path);
pathnode->pathtype = T_SampleScan;
pathnode->parent = rel;
@@ -1018,7 +1030,7 @@ create_index_path(PlannerInfo *root,
double loop_count,
bool partial_path)
{
- IndexPath *pathnode = makeNode(IndexPath);
+ IndexPath *pathnode = makePathNode(root, IndexPath);
RelOptInfo *rel = index->rel;
List *indexquals,
*indexqualcols;
@@ -1070,7 +1082,7 @@ create_bitmap_heap_path(PlannerInfo *root,
Relids required_outer,
double loop_count)
{
- BitmapHeapPath *pathnode = makeNode(BitmapHeapPath);
+ BitmapHeapPath *pathnode = makePathNode(root, BitmapHeapPath);
pathnode->path.pathtype = T_BitmapHeapScan;
pathnode->path.parent = rel;
@@ -1100,7 +1112,7 @@ create_bitmap_and_path(PlannerInfo *root,
RelOptInfo *rel,
List *bitmapquals)
{
- BitmapAndPath *pathnode = makeNode(BitmapAndPath);
+ BitmapAndPath *pathnode = makePathNode(root, BitmapAndPath);
pathnode->path.pathtype = T_BitmapAnd;
pathnode->path.parent = rel;
@@ -1136,7 +1148,7 @@ create_bitmap_or_path(PlannerInfo *root,
RelOptInfo *rel,
List *bitmapquals)
{
- BitmapOrPath *pathnode = makeNode(BitmapOrPath);
+ BitmapOrPath *pathnode = makePathNode(root, BitmapOrPath);
pathnode->path.pathtype = T_BitmapOr;
pathnode->path.parent = rel;
@@ -1171,7 +1183,7 @@ TidPath *
create_tidscan_path(PlannerInfo *root, RelOptInfo *rel, List *tidquals,
Relids required_outer)
{
- TidPath *pathnode = makeNode(TidPath);
+ TidPath *pathnode = makePathNode(root, TidPath);
pathnode->path.pathtype = T_TidScan;
pathnode->path.parent = rel;
@@ -1199,10 +1211,13 @@ create_tidscan_path(PlannerInfo *root, RelOptInfo *rel, List *tidquals,
* Note that we must handle subpaths = NIL, representing a dummy access path.
*/
AppendPath *
-create_append_path(RelOptInfo *rel, List *subpaths, Relids required_outer,
+create_append_path(PlannerInfo *root,
+ RelOptInfo *rel,
+ List *subpaths,
+ Relids required_outer,
int parallel_workers)
{
- AppendPath *pathnode = makeNode(AppendPath);
+ AppendPath *pathnode = makePathNode(root, AppendPath);
ListCell *l;
pathnode->path.pathtype = T_Append;
@@ -1259,7 +1274,7 @@ create_merge_append_path(PlannerInfo *root,
List *pathkeys,
Relids required_outer)
{
- MergeAppendPath *pathnode = makeNode(MergeAppendPath);
+ MergeAppendPath *pathnode = makePathNode(root, MergeAppendPath);
Cost input_startup_cost;
Cost input_total_cost;
ListCell *l;
@@ -1346,7 +1361,7 @@ ResultPath *
create_result_path(PlannerInfo *root, RelOptInfo *rel,
PathTarget *target, List *resconstantqual)
{
- ResultPath *pathnode = makeNode(ResultPath);
+ ResultPath *pathnode = makePathNode(root, ResultPath);
pathnode->path.pathtype = T_Result;
pathnode->path.parent = rel;
@@ -1382,9 +1397,9 @@ create_result_path(PlannerInfo *root, RelOptInfo *rel,
* pathnode.
*/
MaterialPath *
-create_material_path(RelOptInfo *rel, Path *subpath)
+create_material_path(PlannerInfo *root, RelOptInfo *rel, Path *subpath)
{
- MaterialPath *pathnode = makeNode(MaterialPath);
+ MaterialPath *pathnode = makePathNode(root, MaterialPath);
Assert(subpath->parent == rel);
@@ -1451,7 +1466,7 @@ create_unique_path(PlannerInfo *root, RelOptInfo *rel, Path *subpath,
*/
oldcontext = MemoryContextSwitchTo(root->planner_cxt);
- pathnode = makeNode(UniquePath);
+ pathnode = makePathNode(root, UniquePath);
pathnode->path.pathtype = T_Unique;
pathnode->path.parent = rel;
@@ -1667,7 +1682,7 @@ GatherPath *
create_gather_path(PlannerInfo *root, RelOptInfo *rel, Path *subpath,
PathTarget *target, Relids required_outer, double *rows)
{
- GatherPath *pathnode = makeNode(GatherPath);
+ GatherPath *pathnode = makePathNode(root, GatherPath);
Assert(subpath->parallel_safe);
@@ -1705,7 +1720,7 @@ SubqueryScanPath *
create_subqueryscan_path(PlannerInfo *root, RelOptInfo *rel, Path *subpath,
List *pathkeys, Relids required_outer)
{
- SubqueryScanPath *pathnode = makeNode(SubqueryScanPath);
+ SubqueryScanPath *pathnode = makePathNode(root, SubqueryScanPath);
pathnode->path.pathtype = T_SubqueryScan;
pathnode->path.parent = rel;
@@ -1733,7 +1748,7 @@ Path *
create_functionscan_path(PlannerInfo *root, RelOptInfo *rel,
List *pathkeys, Relids required_outer)
{
- Path *pathnode = makeNode(Path);
+ Path *pathnode = makePathNode(root, Path);
pathnode->pathtype = T_FunctionScan;
pathnode->parent = rel;
@@ -1759,7 +1774,7 @@ Path *
create_valuesscan_path(PlannerInfo *root, RelOptInfo *rel,
Relids required_outer)
{
- Path *pathnode = makeNode(Path);
+ Path *pathnode = makePathNode(root, Path);
pathnode->pathtype = T_ValuesScan;
pathnode->parent = rel;
@@ -1784,7 +1799,7 @@ create_valuesscan_path(PlannerInfo *root, RelOptInfo *rel,
Path *
create_ctescan_path(PlannerInfo *root, RelOptInfo *rel, Relids required_outer)
{
- Path *pathnode = makeNode(Path);
+ Path *pathnode = makePathNode(root, Path);
pathnode->pathtype = T_CteScan;
pathnode->parent = rel;
@@ -1810,7 +1825,7 @@ Path *
create_worktablescan_path(PlannerInfo *root, RelOptInfo *rel,
Relids required_outer)
{
- Path *pathnode = makeNode(Path);
+ Path *pathnode = makePathNode(root, Path);
pathnode->pathtype = T_WorkTableScan;
pathnode->parent = rel;
@@ -1849,7 +1864,7 @@ create_foreignscan_path(PlannerInfo *root, RelOptInfo *rel,
Path *fdw_outerpath,
List *fdw_private)
{
- ForeignPath *pathnode = makeNode(ForeignPath);
+ ForeignPath *pathnode = makePathNode(root, ForeignPath);
pathnode->path.pathtype = T_ForeignScan;
pathnode->path.parent = rel;
@@ -1955,7 +1970,7 @@ create_nestloop_path(PlannerInfo *root,
List *pathkeys,
Relids required_outer)
{
- NestPath *pathnode = makeNode(NestPath);
+ NestPath *pathnode = makePathNode(root, NestPath);
Relids inner_req_outer = PATH_REQ_OUTER(inner_path);
/*
@@ -2045,7 +2060,7 @@ create_mergejoin_path(PlannerInfo *root,
List *outersortkeys,
List *innersortkeys)
{
- MergePath *pathnode = makeNode(MergePath);
+ MergePath *pathnode = makePathNode(root, MergePath);
pathnode->jpath.path.pathtype = T_MergeJoin;
pathnode->jpath.path.parent = joinrel;
@@ -2107,7 +2122,7 @@ create_hashjoin_path(PlannerInfo *root,
Relids required_outer,
List *hashclauses)
{
- HashPath *pathnode = makeNode(HashPath);
+ HashPath *pathnode = makePathNode(root, HashPath);
pathnode->jpath.path.pathtype = T_HashJoin;
pathnode->jpath.path.parent = joinrel;
@@ -2164,7 +2179,7 @@ create_projection_path(PlannerInfo *root,
Path *subpath,
PathTarget *target)
{
- ProjectionPath *pathnode = makeNode(ProjectionPath);
+ ProjectionPath *pathnode = makePathNode(root, ProjectionPath);
PathTarget *oldtarget = subpath->pathtarget;
pathnode->path.pathtype = T_Result;
@@ -2331,7 +2346,7 @@ create_set_projection_path(PlannerInfo *root,
Path *subpath,
PathTarget *target)
{
- ProjectSetPath *pathnode = makeNode(ProjectSetPath);
+ ProjectSetPath *pathnode = makePathNode(root, ProjectSetPath);
double tlist_rows;
ListCell *lc;
@@ -2399,7 +2414,7 @@ create_sort_path(PlannerInfo *root,
List *pathkeys,
double limit_tuples)
{
- SortPath *pathnode = makeNode(SortPath);
+ SortPath *pathnode = makePathNode(root, SortPath);
pathnode->path.pathtype = T_Sort;
pathnode->path.parent = rel;
@@ -2445,7 +2460,7 @@ create_group_path(PlannerInfo *root,
List *qual,
double numGroups)
{
- GroupPath *pathnode = makeNode(GroupPath);
+ GroupPath *pathnode = makePathNode(root, GroupPath);
pathnode->path.pathtype = T_Group;
pathnode->path.parent = rel;
@@ -2501,7 +2516,7 @@ create_upper_unique_path(PlannerInfo *root,
int numCols,
double numGroups)
{
- UpperUniquePath *pathnode = makeNode(UpperUniquePath);
+ UpperUniquePath *pathnode = makePathNode(root, UpperUniquePath);
pathnode->path.pathtype = T_Unique;
pathnode->path.parent = rel;
@@ -2558,7 +2573,7 @@ create_agg_path(PlannerInfo *root,
const AggClauseCosts *aggcosts,
double numGroups)
{
- AggPath *pathnode = makeNode(AggPath);
+ AggPath *pathnode = makePathNode(root, AggPath);
pathnode->path.pathtype = T_Agg;
pathnode->path.parent = rel;
@@ -2623,7 +2638,7 @@ create_groupingsets_path(PlannerInfo *root,
const AggClauseCosts *agg_costs,
double numGroups)
{
- GroupingSetsPath *pathnode = makeNode(GroupingSetsPath);
+ GroupingSetsPath *pathnode = makePathNode(root, GroupingSetsPath);
int numGroupCols;
/* The topmost generated Plan node will be an Agg */
@@ -2736,7 +2751,7 @@ create_minmaxagg_path(PlannerInfo *root,
List *mmaggregates,
List *quals)
{
- MinMaxAggPath *pathnode = makeNode(MinMaxAggPath);
+ MinMaxAggPath *pathnode = makePathNode(root, MinMaxAggPath);
Cost initplan_cost;
ListCell *lc;
@@ -2797,7 +2812,7 @@ create_windowagg_path(PlannerInfo *root,
WindowClause *winclause,
List *winpathkeys)
{
- WindowAggPath *pathnode = makeNode(WindowAggPath);
+ WindowAggPath *pathnode = makePathNode(root, WindowAggPath);
pathnode->path.pathtype = T_WindowAgg;
pathnode->path.parent = rel;
@@ -2864,7 +2879,7 @@ create_setop_path(PlannerInfo *root,
double numGroups,
double outputRows)
{
- SetOpPath *pathnode = makeNode(SetOpPath);
+ SetOpPath *pathnode = makePathNode(root, SetOpPath);
pathnode->path.pathtype = T_SetOp;
pathnode->path.parent = rel;
@@ -2924,7 +2939,7 @@ create_recursiveunion_path(PlannerInfo *root,
int wtParam,
double numGroups)
{
- RecursiveUnionPath *pathnode = makeNode(RecursiveUnionPath);
+ RecursiveUnionPath *pathnode = makePathNode(root, RecursiveUnionPath);
pathnode->path.pathtype = T_RecursiveUnion;
pathnode->path.parent = rel;
@@ -2963,7 +2978,7 @@ LockRowsPath *
create_lockrows_path(PlannerInfo *root, RelOptInfo *rel,
Path *subpath, List *rowMarks, int epqParam)
{
- LockRowsPath *pathnode = makeNode(LockRowsPath);
+ LockRowsPath *pathnode = makePathNode(root, LockRowsPath);
pathnode->path.pathtype = T_LockRows;
pathnode->path.parent = rel;
@@ -3025,7 +3040,7 @@ create_modifytable_path(PlannerInfo *root, RelOptInfo *rel,
List *rowMarks, OnConflictExpr *onconflict,
int epqParam)
{
- ModifyTablePath *pathnode = makeNode(ModifyTablePath);
+ ModifyTablePath *pathnode = makePathNode(root, ModifyTablePath);
double total_size;
ListCell *lc;
@@ -3120,7 +3135,7 @@ create_limit_path(PlannerInfo *root, RelOptInfo *rel,
Node *limitOffset, Node *limitCount,
int64 offset_est, int64 count_est)
{
- LimitPath *pathnode = makeNode(LimitPath);
+ LimitPath *pathnode = makePathNode(root, LimitPath);
pathnode->path.pathtype = T_Limit;
pathnode->path.parent = rel;
diff --git a/src/include/nodes/relation.h b/src/include/nodes/relation.h
index f7ac6f6..aa2e9b3 100644
--- a/src/include/nodes/relation.h
+++ b/src/include/nodes/relation.h
@@ -128,6 +128,8 @@ typedef struct PlannerGlobal
bool parallelModeNeeded; /* parallel mode actually required? */
char maxParallelHazard; /* worst PROPARALLEL hazard level */
+
+ MemoryContext path_cxt; /* Temporary context for holding paths. */
} PlannerGlobal;
/* macro for fetching the Plan associated with a SubPlan node */
diff --git a/src/include/optimizer/pathnode.h b/src/include/optimizer/pathnode.h
index 53cad24..18591df 100644
--- a/src/include/optimizer/pathnode.h
+++ b/src/include/optimizer/pathnode.h
@@ -62,8 +62,11 @@ extern BitmapOrPath *create_bitmap_or_path(PlannerInfo *root,
List *bitmapquals);
extern TidPath *create_tidscan_path(PlannerInfo *root, RelOptInfo *rel,
List *tidquals, Relids required_outer);
-extern AppendPath *create_append_path(RelOptInfo *rel, List *subpaths,
- Relids required_outer, int parallel_workers);
+extern AppendPath *create_append_path(PlannerInfo *root,
+ RelOptInfo *rel,
+ List *subpaths,
+ Relids required_outer,
+ int parallel_workers);
extern MergeAppendPath *create_merge_append_path(PlannerInfo *root,
RelOptInfo *rel,
List *subpaths,
@@ -71,7 +74,8 @@ extern MergeAppendPath *create_merge_append_path(PlannerInfo *root,
Relids required_outer);
extern ResultPath *create_result_path(PlannerInfo *root, RelOptInfo *rel,
PathTarget *target, List *resconstantqual);
-extern MaterialPath *create_material_path(RelOptInfo *rel, Path *subpath);
+extern MaterialPath *create_material_path(PlannerInfo *root, RelOptInfo *rel,
+ Path *subpath);
extern UniquePath *create_unique_path(PlannerInfo *root, RelOptInfo *rel,
Path *subpath, SpecialJoinInfo *sjinfo);
extern GatherPath *create_gather_path(PlannerInfo *root,
diff --git a/src/include/optimizer/paths.h b/src/include/optimizer/paths.h
index ebda308..733e40d 100644
--- a/src/include/optimizer/paths.h
+++ b/src/include/optimizer/paths.h
@@ -49,7 +49,7 @@ extern PGDLLIMPORT join_search_hook_type join_search_hook;
extern RelOptInfo *make_one_rel(PlannerInfo *root, List *joinlist);
-extern void set_dummy_rel_pathlist(RelOptInfo *rel);
+extern void set_dummy_rel_pathlist(PlannerInfo *root, RelOptInfo *rel);
extern RelOptInfo *standard_join_search(PlannerInfo *root, int levels_needed,
List *initial_rels);
--
1.7.9.5
[application/octet-stream] 0002-Patch-to-measure-memory-used-in-CurrentMemoryContext.patch (3.1K, ../../CAFjFpRfTHJ5AHd0Ydb+DAsybhcT+2ViiuzKy+yKtOZArQ4eN+g@mail.gmail.com/3-0002-Patch-to-measure-memory-used-in-CurrentMemoryContext.patch)
download | inline diff:
From 4f5bde7a4902e3cd2ef2a1dd4cfec2d93c695966 Mon Sep 17 00:00:00 2001
From: Ashutosh Bapat <[email protected]>
Date: Wed, 1 Mar 2017 12:12:11 +0530
Subject: [PATCH 2/3] Patch to measure memory used in CurrentMemoryContext in
standard_planner().
---
src/backend/optimizer/plan/planner.c | 5 +++++
src/backend/utils/mmgr/mcxt.c | 26 ++++++++++++++++++++++++++
src/include/utils/memutils.h | 6 ++++++
3 files changed, 37 insertions(+)
diff --git a/src/backend/optimizer/plan/planner.c b/src/backend/optimizer/plan/planner.c
index b74e887..410750d 100644
--- a/src/backend/optimizer/plan/planner.c
+++ b/src/backend/optimizer/plan/planner.c
@@ -195,6 +195,9 @@ standard_planner(Query *parse, int cursorOptions, ParamListInfo boundParams)
Plan *top_plan;
ListCell *lp,
*lr;
+ MemoryContextCounters mem_start;
+
+ MemoryContextFuncStatsStart(CurrentMemoryContext, &mem_start, __FUNCTION__);
/*
* Set up global state for this planner invocation. This data is needed
@@ -425,6 +428,8 @@ standard_planner(Query *parse, int cursorOptions, ParamListInfo boundParams)
MemoryContextResetAndDeleteChildren(glob->path_cxt);
glob->path_cxt = NULL;
+ MemoryContextFuncStatsEnd(CurrentMemoryContext, &mem_start, __FUNCTION__);
+
return result;
}
diff --git a/src/backend/utils/mmgr/mcxt.c b/src/backend/utils/mmgr/mcxt.c
index 6ad0bb4..94b25ac 100644
--- a/src/backend/utils/mmgr/mcxt.c
+++ b/src/backend/utils/mmgr/mcxt.c
@@ -577,6 +577,32 @@ MemoryContextStatsInternal(MemoryContext context, int level,
}
}
+void
+MemoryContextFuncStatsStart(MemoryContext context,
+ MemoryContextCounters *start_counts,
+ const char *label)
+{
+ memset(start_counts, 0, sizeof(*start_counts));
+ MemoryContextStatsInternal(context, 0, false, 100, start_counts);
+}
+
+void
+MemoryContextFuncStatsEnd(MemoryContext context,
+ MemoryContextCounters *start_counts,
+ const char *label)
+{
+ MemoryContextCounters end_counts;
+ Size start_used_space = start_counts->totalspace - start_counts->freespace;
+ Size end_used_space;
+
+ memset(&end_counts, 0, sizeof(end_counts));
+ MemoryContextStatsInternal(context, 0, false, 100, &end_counts);
+ end_used_space = end_counts.totalspace - end_counts.freespace;
+
+ elog(NOTICE, "%s,%s,%zu,%zu,%ld", label, context->name,
+ start_used_space, end_used_space, end_used_space - start_used_space);
+}
+
/*
* MemoryContextCheck
* Check all chunks in the named context.
diff --git a/src/include/utils/memutils.h b/src/include/utils/memutils.h
index 1d1035e..7d605b1 100644
--- a/src/include/utils/memutils.h
+++ b/src/include/utils/memutils.h
@@ -122,6 +122,12 @@ extern MemoryContext MemoryContextCreate(NodeTag tag, Size size,
MemoryContextMethods *methods,
MemoryContext parent,
const char *name);
+extern void MemoryContextFuncStatsStart(MemoryContext context,
+ MemoryContextCounters *start_counts,
+ const char *func_label);
+extern void MemoryContextFuncStatsEnd(MemoryContext context,
+ MemoryContextCounters *start_counts,
+ const char *func_label);
/*
--
1.7.9.5
[application/octet-stream] 0003-GUC-zap_path-to-enable-freeing-memory-consumed-by-pa.patch (2.9K, ../../CAFjFpRfTHJ5AHd0Ydb+DAsybhcT+2ViiuzKy+yKtOZArQ4eN+g@mail.gmail.com/4-0003-GUC-zap_path-to-enable-freeing-memory-consumed-by-pa.patch)
download | inline diff:
From 760d328696a460deb418c8fa34b80e53fa530129 Mon Sep 17 00:00:00 2001
From: Ashutosh Bapat <[email protected]>
Date: Wed, 1 Mar 2017 13:29:51 +0530
Subject: [PATCH 3/3] GUC zap_path to enable freeing memory consumed by paths.
For measuring the memory saved, add a GUC zap_path to enable/disable
freeing memory occupied by paths.
---
src/backend/optimizer/path/costsize.c | 1 +
src/backend/optimizer/plan/planner.c | 15 +++++++++------
src/backend/utils/misc/guc.c | 10 ++++++++++
src/include/optimizer/cost.h | 1 +
4 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/src/backend/optimizer/path/costsize.c b/src/backend/optimizer/path/costsize.c
index c138f57..f4dfa00 100644
--- a/src/backend/optimizer/path/costsize.c
+++ b/src/backend/optimizer/path/costsize.c
@@ -126,6 +126,7 @@ bool enable_nestloop = true;
bool enable_material = true;
bool enable_mergejoin = true;
bool enable_hashjoin = true;
+bool zap_paths = true;
typedef struct
{
diff --git a/src/backend/optimizer/plan/planner.c b/src/backend/optimizer/plan/planner.c
index 410750d..c7b085f 100644
--- a/src/backend/optimizer/plan/planner.c
+++ b/src/backend/optimizer/plan/planner.c
@@ -421,12 +421,15 @@ standard_planner(Query *parse, int cursorOptions, ParamListInfo boundParams)
result->stmt_location = parse->stmt_location;
result->stmt_len = parse->stmt_len;
- /*
- * We do not need paths any more, blow those away.
- * TODO: probably we should also set the pathlists to NIL.
- */
- MemoryContextResetAndDeleteChildren(glob->path_cxt);
- glob->path_cxt = NULL;
+ if (zap_paths)
+ {
+ /*
+ * We do not need paths any more, blow those away.
+ * TODO: probably we should also set the pathlists to NIL.
+ */
+ MemoryContextResetAndDeleteChildren(glob->path_cxt);
+ glob->path_cxt = NULL;
+ }
MemoryContextFuncStatsEnd(CurrentMemoryContext, &mem_start, __FUNCTION__);
diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c
index 2477138..630d3f7 100644
--- a/src/backend/utils/misc/guc.c
+++ b/src/backend/utils/misc/guc.c
@@ -912,6 +912,16 @@ static struct config_bool ConfigureNamesBool[] =
true,
NULL, NULL, NULL
},
+
+ {
+ {"zap_paths", PGC_USERSET, QUERY_TUNING_GEQO,
+ gettext_noop("Free up the memory used by paths at the end of planning."),
+ },
+ &zap_paths,
+ true,
+ NULL, NULL, NULL
+ },
+
{
/* Not for general use --- used by SET SESSION AUTHORIZATION */
{"is_superuser", PGC_INTERNAL, UNGROUPED,
diff --git a/src/include/optimizer/cost.h b/src/include/optimizer/cost.h
index 72200fa..fc882ad 100644
--- a/src/include/optimizer/cost.h
+++ b/src/include/optimizer/cost.h
@@ -67,6 +67,7 @@ extern bool enable_material;
extern bool enable_mergejoin;
extern bool enable_hashjoin;
extern int constraint_exclusion;
+extern bool zap_paths;
extern double clamp_row_est(double nrows);
extern double index_pages_fetched(double tuples_fetched, BlockNumber pages,
--
1.7.9.5
[application/octet-stream] path_memory.out (3.0K, ../../CAFjFpRfTHJ5AHd0Ydb+DAsybhcT+2ViiuzKy+yKtOZArQ4eN+g@mail.gmail.com/5-path_memory.out)
download
[application/octet-stream] path_memory.sql (381B, ../../CAFjFpRfTHJ5AHd0Ydb+DAsybhcT+2ViiuzKy+yKtOZArQ4eN+g@mail.gmail.com/6-path_memory.sql)
download
^ permalink raw reply [nested|flat] 277+ messages in thread
* Re: Partition-wise join for join between (declaratively) partitioned tables
2017-03-01 08:56 Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
@ 2017-03-02 04:52 ` Ashutosh Bapat <[email protected]>
1 sibling, 0 replies; 277+ messages in thread
From: Ashutosh Bapat @ 2017-03-02 04:52 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: Rajkumar Raghuwanshi <[email protected]>; pgsql-hackers
Updated 0001 patch with some more comments. Attaching all the patches
for quick access.
On Wed, Mar 1, 2017 at 2:26 PM, Ashutosh Bapat
<[email protected]> wrote:
>>
>> 2. If the PartitionJoinPath emerges as the best path, we create paths
>> for each of the remaining child-joins. Then we collect paths with
>> properties same as the given PartitionJoinPath, one from each
>> child-join. These paths are converted into plans and a Merge/Append
>> plan is created combing these plans. The paths and plans for
>> child-join are created in a temporary memory context. The final plan
>> for each child-join is copied into planner's context and the temporary
>> memory context is reset.
>>
>
> Robert and I discussed this in more detail. Path creation code may
> allocate objects other than paths. postgres_fdw, for example,
> allocates character array to hold the name of relation being
> pushed-down. When the temporary context gets zapped after creating
> paths for a given child-join, those other objects also gets thrown
> away. Attached patch has implemented the idea that came out of the
> discussion.
>
> We create a memory context for holding paths at the time of creating
> PlannerGlobal and save it in PlannerGlobal. The patch introduces a new
> macro makePathNode() which allocates the memory for given type of path
> from this context. Every create_*_path function has been changed to
> use this macro instead of makeNode(). In standard_planner(), at the
> end of planning we destroy the memory context freeing all the paths
> allocated. While creating a plan node, planner copies everything
> required by the plan from the path, so the path is not needed any
> more. So, freeing corresponding memory should not have any adverse
> effects.
>
> Most of the create_*_path() functions accept root as an argument, thus
> the temporary path context is available through root->glob everywhere.
> An exception is create_append_path() which does not accept root as an
> argument. The patch changes create_append_path() and its callers like
> set_dummy_rel_pathlist(), mark_dummy_rel() to accept root as an
> argument. Ideally paths are not required after creating plan, so we
> should be
> able to free the context right after the call to create_plan(). But we
> need dummy paths while creating flat rtable in
> set_plan_references()->add_rtes_to_flat_rtable(). We used to So free
> the path context at the end of planning cycle. Now that we are
> allocating all the paths in a different memory context, it doesn't
> make sense to switch context in mark_dummy_rel().
>
> 0001 patch implements the idea described above.
> 0002 patch adds instrumentation to measure memory consumed in
> standard_planner() call.
> 0003 patch adds a GUC zap_paths to enable/disable destroying path context.
> The last two patches are for testing only.
>
> Attached also find the SQL script and its output showing the memory
> saved. For a 5 way self-join of pg_class, the total memory consumed in
> standard_planner() is 760K without patch and with patch it comes down
> to 713K, saving 47K memory otherwise occupied by paths. It looks like
> something useful even without partition-wise joins.
>
> --
> Best Wishes,
> Ashutosh Bapat
> EnterpriseDB Corporation
> The Postgres Database Company
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Attachments:
[application/octet-stream] 0001-Free-up-memory-consumed-by-the-paths.patch (28.5K, ../../CAFjFpRem9PpMPXuJNrTTjike1gseRbSWUjJbx=5cD9Qi1egvoQ@mail.gmail.com/2-0001-Free-up-memory-consumed-by-the-paths.patch)
download | inline diff:
From 02bca46338c9623735b466ccda52265fece6cafe Mon Sep 17 00:00:00 2001
From: Ashutosh Bapat <[email protected]>
Date: Wed, 1 Mar 2017 11:07:28 +0530
Subject: [PATCH 1/3] Free up memory consumed by the paths.
Optimizer creates many paths while planning the query. Only one path
tree gets converted to the plan. Paths continue to occupy memory even
after the plan is created. For an un-PREPAREd query, it means that the
memory remains occupied till the end of the execution. Since plan node
copies the relevant information from the corresponding path, paths are
not needed after plan is created. We can free up that memory.
While creating global planner structure (PlannerGlob) we allocate a
separate memory context for creating paths. Every create_*_path()
function allocates path node in this context. The context is freed at
the end of planning cycle after creating PlannedStmt.
Ideally paths are not required after creating plan, so we should be
able to free the context right after the call to create_plan(). But we
need dummy paths while creating flat rtable in
set_plan_references()->add_rtes_to_flat_rtable(). There might be other
corner cases where we need paths. So free the path context at the end
of planning cycle.
Now that we have separate memory context to hold paths, we don't need
to switch contexts in make_dummy_rel().
---
src/backend/optimizer/path/allpaths.c | 25 ++++----
src/backend/optimizer/path/joinpath.c | 2 +-
src/backend/optimizer/path/joinrels.c | 37 ++++--------
src/backend/optimizer/plan/planner.c | 16 ++++-
src/backend/optimizer/prep/prepunion.c | 4 +-
src/backend/optimizer/util/pathnode.c | 100 ++++++++++++++++++++------------
src/include/nodes/relation.h | 2 +
src/include/optimizer/pathnode.h | 10 +++-
src/include/optimizer/paths.h | 2 +-
9 files changed, 113 insertions(+), 85 deletions(-)
diff --git a/src/backend/optimizer/path/allpaths.c b/src/backend/optimizer/path/allpaths.c
index 633b5c1..e22817e 100644
--- a/src/backend/optimizer/path/allpaths.c
+++ b/src/backend/optimizer/path/allpaths.c
@@ -325,7 +325,7 @@ set_rel_size(PlannerInfo *root, RelOptInfo *rel,
* we don't have a convention for marking a rel as dummy except by
* assigning a dummy path to it.
*/
- set_dummy_rel_pathlist(rel);
+ set_dummy_rel_pathlist(root, rel);
}
else if (rte->inh)
{
@@ -769,7 +769,7 @@ set_tablesample_rel_pathlist(PlannerInfo *root, RelOptInfo *rel, RangeTblEntry *
bms_membership(root->all_baserels) != BMS_SINGLETON) &&
!(GetTsmRoutine(rte->tablesample->tsmhandler)->repeatable_across_scans))
{
- path = (Path *) create_material_path(rel, path);
+ path = (Path *) create_material_path(root, rel, path);
}
add_path(rel, path);
@@ -993,7 +993,7 @@ set_append_rel_size(PlannerInfo *root, RelOptInfo *rel,
* Some restriction clause reduced to constant FALSE or NULL after
* substitution, so this child need not be scanned.
*/
- set_dummy_rel_pathlist(childrel);
+ set_dummy_rel_pathlist(root, childrel);
continue;
}
@@ -1003,7 +1003,7 @@ set_append_rel_size(PlannerInfo *root, RelOptInfo *rel,
* This child need not be scanned, so we can omit it from the
* appendrel.
*/
- set_dummy_rel_pathlist(childrel);
+ set_dummy_rel_pathlist(root, childrel);
continue;
}
@@ -1153,7 +1153,7 @@ set_append_rel_size(PlannerInfo *root, RelOptInfo *rel,
* appendrel dummy. We must do this in this phase so that the rel's
* dummy-ness is visible when we generate paths for other rels.
*/
- set_dummy_rel_pathlist(rel);
+ set_dummy_rel_pathlist(root, rel);
}
pfree(parent_attrsizes);
@@ -1314,7 +1314,8 @@ set_append_rel_pathlist(PlannerInfo *root, RelOptInfo *rel,
* if we have zero or one live subpath due to constraint exclusion.)
*/
if (subpaths_valid)
- add_path(rel, (Path *) create_append_path(rel, subpaths, NULL, 0));
+ add_path(rel, (Path *) create_append_path(root, rel, subpaths, NULL,
+ 0));
/*
* Consider an append of partial unordered, unparameterized partial paths.
@@ -1340,7 +1341,7 @@ set_append_rel_pathlist(PlannerInfo *root, RelOptInfo *rel,
Assert(parallel_workers > 0);
/* Generate a partial append path. */
- appendpath = create_append_path(rel, partial_subpaths, NULL,
+ appendpath = create_append_path(root, rel, partial_subpaths, NULL,
parallel_workers);
add_partial_path(rel, (Path *) appendpath);
}
@@ -1392,8 +1393,8 @@ set_append_rel_pathlist(PlannerInfo *root, RelOptInfo *rel,
}
if (subpaths_valid)
- add_path(rel, (Path *)
- create_append_path(rel, subpaths, required_outer, 0));
+ add_path(rel, (Path *) create_append_path(root, rel, subpaths,
+ required_outer, 0));
}
}
@@ -1613,7 +1614,7 @@ accumulate_append_subpath(List *subpaths, Path *path)
* This is exported because inheritance_planner() has need for it.
*/
void
-set_dummy_rel_pathlist(RelOptInfo *rel)
+set_dummy_rel_pathlist(PlannerInfo *root, RelOptInfo *rel)
{
/* Set dummy size estimates --- we leave attr_widths[] as zeroes */
rel->rows = 0;
@@ -1623,7 +1624,7 @@ set_dummy_rel_pathlist(RelOptInfo *rel)
rel->pathlist = NIL;
rel->partial_pathlist = NIL;
- add_path(rel, (Path *) create_append_path(rel, NIL, NULL, 0));
+ add_path(rel, (Path *) create_append_path(root, rel, NIL, NULL, 0));
/*
* We set the cheapest path immediately, to ensure that IS_DUMMY_REL()
@@ -1808,7 +1809,7 @@ set_subquery_pathlist(PlannerInfo *root, RelOptInfo *rel,
if (IS_DUMMY_REL(sub_final_rel))
{
- set_dummy_rel_pathlist(rel);
+ set_dummy_rel_pathlist(root, rel);
return;
}
diff --git a/src/backend/optimizer/path/joinpath.c b/src/backend/optimizer/path/joinpath.c
index 2897245..2a0f6d9 100644
--- a/src/backend/optimizer/path/joinpath.c
+++ b/src/backend/optimizer/path/joinpath.c
@@ -1124,7 +1124,7 @@ match_unsorted_outer(PlannerInfo *root,
if (enable_material && inner_cheapest_total != NULL &&
!ExecMaterializesOutput(inner_cheapest_total->pathtype))
matpath = (Path *)
- create_material_path(innerrel, inner_cheapest_total);
+ create_material_path(root, innerrel, inner_cheapest_total);
}
foreach(lc1, outerrel->pathlist)
diff --git a/src/backend/optimizer/path/joinrels.c b/src/backend/optimizer/path/joinrels.c
index 0d00683..f0c8b62 100644
--- a/src/backend/optimizer/path/joinrels.c
+++ b/src/backend/optimizer/path/joinrels.c
@@ -29,7 +29,7 @@ static void make_rels_by_clauseless_joins(PlannerInfo *root,
static bool has_join_restriction(PlannerInfo *root, RelOptInfo *rel);
static bool has_legal_joinclause(PlannerInfo *root, RelOptInfo *rel);
static bool is_dummy_rel(RelOptInfo *rel);
-static void mark_dummy_rel(RelOptInfo *rel);
+static void mark_dummy_rel(PlannerInfo *root, RelOptInfo *rel);
static bool restriction_is_constant_false(List *restrictlist,
bool only_pushed_down);
@@ -748,7 +748,7 @@ make_join_rel(PlannerInfo *root, RelOptInfo *rel1, RelOptInfo *rel2)
if (is_dummy_rel(rel1) || is_dummy_rel(rel2) ||
restriction_is_constant_false(restrictlist, false))
{
- mark_dummy_rel(joinrel);
+ mark_dummy_rel(root, joinrel);
break;
}
add_paths_to_joinrel(root, joinrel, rel1, rel2,
@@ -762,12 +762,12 @@ make_join_rel(PlannerInfo *root, RelOptInfo *rel1, RelOptInfo *rel2)
if (is_dummy_rel(rel1) ||
restriction_is_constant_false(restrictlist, true))
{
- mark_dummy_rel(joinrel);
+ mark_dummy_rel(root, joinrel);
break;
}
if (restriction_is_constant_false(restrictlist, false) &&
bms_is_subset(rel2->relids, sjinfo->syn_righthand))
- mark_dummy_rel(rel2);
+ mark_dummy_rel(root, rel2);
add_paths_to_joinrel(root, joinrel, rel1, rel2,
JOIN_LEFT, sjinfo,
restrictlist);
@@ -779,7 +779,7 @@ make_join_rel(PlannerInfo *root, RelOptInfo *rel1, RelOptInfo *rel2)
if ((is_dummy_rel(rel1) && is_dummy_rel(rel2)) ||
restriction_is_constant_false(restrictlist, true))
{
- mark_dummy_rel(joinrel);
+ mark_dummy_rel(root, joinrel);
break;
}
add_paths_to_joinrel(root, joinrel, rel1, rel2,
@@ -815,7 +815,7 @@ make_join_rel(PlannerInfo *root, RelOptInfo *rel1, RelOptInfo *rel2)
if (is_dummy_rel(rel1) || is_dummy_rel(rel2) ||
restriction_is_constant_false(restrictlist, false))
{
- mark_dummy_rel(joinrel);
+ mark_dummy_rel(root, joinrel);
break;
}
add_paths_to_joinrel(root, joinrel, rel1, rel2,
@@ -838,7 +838,7 @@ make_join_rel(PlannerInfo *root, RelOptInfo *rel1, RelOptInfo *rel2)
if (is_dummy_rel(rel1) || is_dummy_rel(rel2) ||
restriction_is_constant_false(restrictlist, false))
{
- mark_dummy_rel(joinrel);
+ mark_dummy_rel(root, joinrel);
break;
}
add_paths_to_joinrel(root, joinrel, rel1, rel2,
@@ -853,12 +853,12 @@ make_join_rel(PlannerInfo *root, RelOptInfo *rel1, RelOptInfo *rel2)
if (is_dummy_rel(rel1) ||
restriction_is_constant_false(restrictlist, true))
{
- mark_dummy_rel(joinrel);
+ mark_dummy_rel(root, joinrel);
break;
}
if (restriction_is_constant_false(restrictlist, false) &&
bms_is_subset(rel2->relids, sjinfo->syn_righthand))
- mark_dummy_rel(rel2);
+ mark_dummy_rel(root, rel2);
add_paths_to_joinrel(root, joinrel, rel1, rel2,
JOIN_ANTI, sjinfo,
restrictlist);
@@ -1168,27 +1168,14 @@ is_dummy_rel(RelOptInfo *rel)
* During GEQO planning, this can get invoked more than once on the same
* baserel struct, so it's worth checking to see if the rel is already marked
* dummy.
- *
- * Also, when called during GEQO join planning, we are in a short-lived
- * memory context. We must make sure that the dummy path attached to a
- * baserel survives the GEQO cycle, else the baserel is trashed for future
- * GEQO cycles. On the other hand, when we are marking a joinrel during GEQO,
- * we don't want the dummy path to clutter the main planning context. Upshot
- * is that the best solution is to explicitly make the dummy path in the same
- * context the given RelOptInfo is in.
*/
static void
-mark_dummy_rel(RelOptInfo *rel)
+mark_dummy_rel(PlannerInfo *root, RelOptInfo *rel)
{
- MemoryContext oldcontext;
-
/* Already marked? */
if (is_dummy_rel(rel))
return;
- /* No, so choose correct context to make the dummy path in */
- oldcontext = MemoryContextSwitchTo(GetMemoryChunkContext(rel));
-
/* Set dummy size estimate */
rel->rows = 0;
@@ -1197,12 +1184,10 @@ mark_dummy_rel(RelOptInfo *rel)
rel->partial_pathlist = NIL;
/* Set up the dummy path */
- add_path(rel, (Path *) create_append_path(rel, NIL, NULL, 0));
+ add_path(rel, (Path *) create_append_path(root, rel, NIL, NULL, 0));
/* Set or update cheapest_total_path and related fields */
set_cheapest(rel);
-
- MemoryContextSwitchTo(oldcontext);
}
diff --git a/src/backend/optimizer/plan/planner.c b/src/backend/optimizer/plan/planner.c
index ca0ae78..b74e887 100644
--- a/src/backend/optimizer/plan/planner.c
+++ b/src/backend/optimizer/plan/planner.c
@@ -54,6 +54,7 @@
#include "utils/rel.h"
#include "utils/selfuncs.h"
#include "utils/lsyscache.h"
+#include "utils/memutils.h"
#include "utils/syscache.h"
@@ -218,6 +219,9 @@ standard_planner(Query *parse, int cursorOptions, ParamListInfo boundParams)
glob->lastPlanNodeId = 0;
glob->transientPlan = false;
glob->dependsOnRole = false;
+ glob->path_cxt = AllocSetContextCreate(CurrentMemoryContext,
+ "Path creation temporary context",
+ ALLOCSET_DEFAULT_SIZES);
/*
* Assess whether it's feasible to use parallel mode for this query. We
@@ -414,6 +418,13 @@ standard_planner(Query *parse, int cursorOptions, ParamListInfo boundParams)
result->stmt_location = parse->stmt_location;
result->stmt_len = parse->stmt_len;
+ /*
+ * We do not need paths any more, blow those away.
+ * TODO: probably we should also set the pathlists to NIL.
+ */
+ MemoryContextResetAndDeleteChildren(glob->path_cxt);
+ glob->path_cxt = NULL;
+
return result;
}
@@ -1302,7 +1313,7 @@ inheritance_planner(PlannerInfo *root)
*/
if (subpaths == NIL)
{
- set_dummy_rel_pathlist(final_rel);
+ set_dummy_rel_pathlist(root, final_rel);
return;
}
@@ -3334,7 +3345,7 @@ create_grouping_paths(PlannerInfo *root,
paths = lappend(paths, path);
}
path = (Path *)
- create_append_path(grouped_rel,
+ create_append_path(root, grouped_rel,
paths,
NULL,
0);
@@ -5261,6 +5272,7 @@ plan_cluster_use_sort(Oid tableOid, Oid indexOid)
query->commandType = CMD_SELECT;
glob = makeNode(PlannerGlobal);
+ glob->path_cxt = CurrentMemoryContext;
root = makeNode(PlannerInfo);
root->parse = query;
diff --git a/src/backend/optimizer/prep/prepunion.c b/src/backend/optimizer/prep/prepunion.c
index 1389db1..492f8df 100644
--- a/src/backend/optimizer/prep/prepunion.c
+++ b/src/backend/optimizer/prep/prepunion.c
@@ -566,7 +566,7 @@ generate_union_path(SetOperationStmt *op, PlannerInfo *root,
/*
* Append the child results together.
*/
- path = (Path *) create_append_path(result_rel, pathlist, NULL, 0);
+ path = (Path *) create_append_path(root, result_rel, pathlist, NULL, 0);
/* We have to manually jam the right tlist into the path; ick */
path->pathtarget = create_pathtarget(root, tlist);
@@ -678,7 +678,7 @@ generate_nonunion_path(SetOperationStmt *op, PlannerInfo *root,
/*
* Append the child results together.
*/
- path = (Path *) create_append_path(result_rel, pathlist, NULL, 0);
+ path = (Path *) create_append_path(root, result_rel, pathlist, NULL, 0);
/* We have to manually jam the right tlist into the path; ick */
path->pathtarget = create_pathtarget(root, tlist);
diff --git a/src/backend/optimizer/util/pathnode.c b/src/backend/optimizer/util/pathnode.c
index 3248296..3f1184c 100644
--- a/src/backend/optimizer/util/pathnode.c
+++ b/src/backend/optimizer/util/pathnode.c
@@ -930,6 +930,27 @@ add_partial_path_precheck(RelOptInfo *parent_rel, Cost total_cost,
*****************************************************************************/
/*
+ * The memory consumed by paths remains occupied after the plan is created.
+ * For an un-PREPAREd query, it means that the paths continue to occupy the
+ * memory till the end of the execution. Since plan node copies the relevant
+ * information from the corresponding path, paths are not needed after plan is
+ * created. Following macro creates specified Path node in a temporary memory
+ * context allocated while creating PlannerGlobal. This memory context is
+ * reset at the end of planning to free up any memory consumed by paths.
+ */
+#define makePathNode(root, _type_) ((_type_ *) newPath((root), sizeof(_type_),T_##_type_))
+static Path *
+newPath(PlannerInfo *root, size_t size, NodeTag tag)
+{
+ Path *result;
+
+ Assert(sizeof(Path) <= size);
+ result = MemoryContextAllocZero(root->glob->path_cxt, size);
+ result->type = tag;
+ return result;
+}
+
+/*
* create_seqscan_path
* Creates a path corresponding to a sequential scan, returning the
* pathnode.
@@ -938,7 +959,7 @@ Path *
create_seqscan_path(PlannerInfo *root, RelOptInfo *rel,
Relids required_outer, int parallel_workers)
{
- Path *pathnode = makeNode(Path);
+ Path *pathnode = makePathNode(root, Path);
pathnode->pathtype = T_SeqScan;
pathnode->parent = rel;
@@ -962,7 +983,7 @@ create_seqscan_path(PlannerInfo *root, RelOptInfo *rel,
Path *
create_samplescan_path(PlannerInfo *root, RelOptInfo *rel, Relids required_outer)
{
- Path *pathnode = makeNode(Path);
+ Path *pathnode = makePathNode(root, Path);
pathnode->pathtype = T_SampleScan;
pathnode->parent = rel;
@@ -1018,7 +1039,7 @@ create_index_path(PlannerInfo *root,
double loop_count,
bool partial_path)
{
- IndexPath *pathnode = makeNode(IndexPath);
+ IndexPath *pathnode = makePathNode(root, IndexPath);
RelOptInfo *rel = index->rel;
List *indexquals,
*indexqualcols;
@@ -1070,7 +1091,7 @@ create_bitmap_heap_path(PlannerInfo *root,
Relids required_outer,
double loop_count)
{
- BitmapHeapPath *pathnode = makeNode(BitmapHeapPath);
+ BitmapHeapPath *pathnode = makePathNode(root, BitmapHeapPath);
pathnode->path.pathtype = T_BitmapHeapScan;
pathnode->path.parent = rel;
@@ -1100,7 +1121,7 @@ create_bitmap_and_path(PlannerInfo *root,
RelOptInfo *rel,
List *bitmapquals)
{
- BitmapAndPath *pathnode = makeNode(BitmapAndPath);
+ BitmapAndPath *pathnode = makePathNode(root, BitmapAndPath);
pathnode->path.pathtype = T_BitmapAnd;
pathnode->path.parent = rel;
@@ -1136,7 +1157,7 @@ create_bitmap_or_path(PlannerInfo *root,
RelOptInfo *rel,
List *bitmapquals)
{
- BitmapOrPath *pathnode = makeNode(BitmapOrPath);
+ BitmapOrPath *pathnode = makePathNode(root, BitmapOrPath);
pathnode->path.pathtype = T_BitmapOr;
pathnode->path.parent = rel;
@@ -1171,7 +1192,7 @@ TidPath *
create_tidscan_path(PlannerInfo *root, RelOptInfo *rel, List *tidquals,
Relids required_outer)
{
- TidPath *pathnode = makeNode(TidPath);
+ TidPath *pathnode = makePathNode(root, TidPath);
pathnode->path.pathtype = T_TidScan;
pathnode->path.parent = rel;
@@ -1199,10 +1220,13 @@ create_tidscan_path(PlannerInfo *root, RelOptInfo *rel, List *tidquals,
* Note that we must handle subpaths = NIL, representing a dummy access path.
*/
AppendPath *
-create_append_path(RelOptInfo *rel, List *subpaths, Relids required_outer,
+create_append_path(PlannerInfo *root,
+ RelOptInfo *rel,
+ List *subpaths,
+ Relids required_outer,
int parallel_workers)
{
- AppendPath *pathnode = makeNode(AppendPath);
+ AppendPath *pathnode = makePathNode(root, AppendPath);
ListCell *l;
pathnode->path.pathtype = T_Append;
@@ -1259,7 +1283,7 @@ create_merge_append_path(PlannerInfo *root,
List *pathkeys,
Relids required_outer)
{
- MergeAppendPath *pathnode = makeNode(MergeAppendPath);
+ MergeAppendPath *pathnode = makePathNode(root, MergeAppendPath);
Cost input_startup_cost;
Cost input_total_cost;
ListCell *l;
@@ -1346,7 +1370,7 @@ ResultPath *
create_result_path(PlannerInfo *root, RelOptInfo *rel,
PathTarget *target, List *resconstantqual)
{
- ResultPath *pathnode = makeNode(ResultPath);
+ ResultPath *pathnode = makePathNode(root, ResultPath);
pathnode->path.pathtype = T_Result;
pathnode->path.parent = rel;
@@ -1382,9 +1406,9 @@ create_result_path(PlannerInfo *root, RelOptInfo *rel,
* pathnode.
*/
MaterialPath *
-create_material_path(RelOptInfo *rel, Path *subpath)
+create_material_path(PlannerInfo *root, RelOptInfo *rel, Path *subpath)
{
- MaterialPath *pathnode = makeNode(MaterialPath);
+ MaterialPath *pathnode = makePathNode(root, MaterialPath);
Assert(subpath->parent == rel);
@@ -1451,7 +1475,7 @@ create_unique_path(PlannerInfo *root, RelOptInfo *rel, Path *subpath,
*/
oldcontext = MemoryContextSwitchTo(root->planner_cxt);
- pathnode = makeNode(UniquePath);
+ pathnode = makePathNode(root, UniquePath);
pathnode->path.pathtype = T_Unique;
pathnode->path.parent = rel;
@@ -1667,7 +1691,7 @@ GatherPath *
create_gather_path(PlannerInfo *root, RelOptInfo *rel, Path *subpath,
PathTarget *target, Relids required_outer, double *rows)
{
- GatherPath *pathnode = makeNode(GatherPath);
+ GatherPath *pathnode = makePathNode(root, GatherPath);
Assert(subpath->parallel_safe);
@@ -1705,7 +1729,7 @@ SubqueryScanPath *
create_subqueryscan_path(PlannerInfo *root, RelOptInfo *rel, Path *subpath,
List *pathkeys, Relids required_outer)
{
- SubqueryScanPath *pathnode = makeNode(SubqueryScanPath);
+ SubqueryScanPath *pathnode = makePathNode(root, SubqueryScanPath);
pathnode->path.pathtype = T_SubqueryScan;
pathnode->path.parent = rel;
@@ -1733,7 +1757,7 @@ Path *
create_functionscan_path(PlannerInfo *root, RelOptInfo *rel,
List *pathkeys, Relids required_outer)
{
- Path *pathnode = makeNode(Path);
+ Path *pathnode = makePathNode(root, Path);
pathnode->pathtype = T_FunctionScan;
pathnode->parent = rel;
@@ -1759,7 +1783,7 @@ Path *
create_valuesscan_path(PlannerInfo *root, RelOptInfo *rel,
Relids required_outer)
{
- Path *pathnode = makeNode(Path);
+ Path *pathnode = makePathNode(root, Path);
pathnode->pathtype = T_ValuesScan;
pathnode->parent = rel;
@@ -1784,7 +1808,7 @@ create_valuesscan_path(PlannerInfo *root, RelOptInfo *rel,
Path *
create_ctescan_path(PlannerInfo *root, RelOptInfo *rel, Relids required_outer)
{
- Path *pathnode = makeNode(Path);
+ Path *pathnode = makePathNode(root, Path);
pathnode->pathtype = T_CteScan;
pathnode->parent = rel;
@@ -1810,7 +1834,7 @@ Path *
create_worktablescan_path(PlannerInfo *root, RelOptInfo *rel,
Relids required_outer)
{
- Path *pathnode = makeNode(Path);
+ Path *pathnode = makePathNode(root, Path);
pathnode->pathtype = T_WorkTableScan;
pathnode->parent = rel;
@@ -1849,7 +1873,7 @@ create_foreignscan_path(PlannerInfo *root, RelOptInfo *rel,
Path *fdw_outerpath,
List *fdw_private)
{
- ForeignPath *pathnode = makeNode(ForeignPath);
+ ForeignPath *pathnode = makePathNode(root, ForeignPath);
pathnode->path.pathtype = T_ForeignScan;
pathnode->path.parent = rel;
@@ -1955,7 +1979,7 @@ create_nestloop_path(PlannerInfo *root,
List *pathkeys,
Relids required_outer)
{
- NestPath *pathnode = makeNode(NestPath);
+ NestPath *pathnode = makePathNode(root, NestPath);
Relids inner_req_outer = PATH_REQ_OUTER(inner_path);
/*
@@ -2045,7 +2069,7 @@ create_mergejoin_path(PlannerInfo *root,
List *outersortkeys,
List *innersortkeys)
{
- MergePath *pathnode = makeNode(MergePath);
+ MergePath *pathnode = makePathNode(root, MergePath);
pathnode->jpath.path.pathtype = T_MergeJoin;
pathnode->jpath.path.parent = joinrel;
@@ -2107,7 +2131,7 @@ create_hashjoin_path(PlannerInfo *root,
Relids required_outer,
List *hashclauses)
{
- HashPath *pathnode = makeNode(HashPath);
+ HashPath *pathnode = makePathNode(root, HashPath);
pathnode->jpath.path.pathtype = T_HashJoin;
pathnode->jpath.path.parent = joinrel;
@@ -2164,7 +2188,7 @@ create_projection_path(PlannerInfo *root,
Path *subpath,
PathTarget *target)
{
- ProjectionPath *pathnode = makeNode(ProjectionPath);
+ ProjectionPath *pathnode = makePathNode(root, ProjectionPath);
PathTarget *oldtarget = subpath->pathtarget;
pathnode->path.pathtype = T_Result;
@@ -2331,7 +2355,7 @@ create_set_projection_path(PlannerInfo *root,
Path *subpath,
PathTarget *target)
{
- ProjectSetPath *pathnode = makeNode(ProjectSetPath);
+ ProjectSetPath *pathnode = makePathNode(root, ProjectSetPath);
double tlist_rows;
ListCell *lc;
@@ -2399,7 +2423,7 @@ create_sort_path(PlannerInfo *root,
List *pathkeys,
double limit_tuples)
{
- SortPath *pathnode = makeNode(SortPath);
+ SortPath *pathnode = makePathNode(root, SortPath);
pathnode->path.pathtype = T_Sort;
pathnode->path.parent = rel;
@@ -2445,7 +2469,7 @@ create_group_path(PlannerInfo *root,
List *qual,
double numGroups)
{
- GroupPath *pathnode = makeNode(GroupPath);
+ GroupPath *pathnode = makePathNode(root, GroupPath);
pathnode->path.pathtype = T_Group;
pathnode->path.parent = rel;
@@ -2501,7 +2525,7 @@ create_upper_unique_path(PlannerInfo *root,
int numCols,
double numGroups)
{
- UpperUniquePath *pathnode = makeNode(UpperUniquePath);
+ UpperUniquePath *pathnode = makePathNode(root, UpperUniquePath);
pathnode->path.pathtype = T_Unique;
pathnode->path.parent = rel;
@@ -2558,7 +2582,7 @@ create_agg_path(PlannerInfo *root,
const AggClauseCosts *aggcosts,
double numGroups)
{
- AggPath *pathnode = makeNode(AggPath);
+ AggPath *pathnode = makePathNode(root, AggPath);
pathnode->path.pathtype = T_Agg;
pathnode->path.parent = rel;
@@ -2623,7 +2647,7 @@ create_groupingsets_path(PlannerInfo *root,
const AggClauseCosts *agg_costs,
double numGroups)
{
- GroupingSetsPath *pathnode = makeNode(GroupingSetsPath);
+ GroupingSetsPath *pathnode = makePathNode(root, GroupingSetsPath);
int numGroupCols;
/* The topmost generated Plan node will be an Agg */
@@ -2736,7 +2760,7 @@ create_minmaxagg_path(PlannerInfo *root,
List *mmaggregates,
List *quals)
{
- MinMaxAggPath *pathnode = makeNode(MinMaxAggPath);
+ MinMaxAggPath *pathnode = makePathNode(root, MinMaxAggPath);
Cost initplan_cost;
ListCell *lc;
@@ -2797,7 +2821,7 @@ create_windowagg_path(PlannerInfo *root,
WindowClause *winclause,
List *winpathkeys)
{
- WindowAggPath *pathnode = makeNode(WindowAggPath);
+ WindowAggPath *pathnode = makePathNode(root, WindowAggPath);
pathnode->path.pathtype = T_WindowAgg;
pathnode->path.parent = rel;
@@ -2864,7 +2888,7 @@ create_setop_path(PlannerInfo *root,
double numGroups,
double outputRows)
{
- SetOpPath *pathnode = makeNode(SetOpPath);
+ SetOpPath *pathnode = makePathNode(root, SetOpPath);
pathnode->path.pathtype = T_SetOp;
pathnode->path.parent = rel;
@@ -2924,7 +2948,7 @@ create_recursiveunion_path(PlannerInfo *root,
int wtParam,
double numGroups)
{
- RecursiveUnionPath *pathnode = makeNode(RecursiveUnionPath);
+ RecursiveUnionPath *pathnode = makePathNode(root, RecursiveUnionPath);
pathnode->path.pathtype = T_RecursiveUnion;
pathnode->path.parent = rel;
@@ -2963,7 +2987,7 @@ LockRowsPath *
create_lockrows_path(PlannerInfo *root, RelOptInfo *rel,
Path *subpath, List *rowMarks, int epqParam)
{
- LockRowsPath *pathnode = makeNode(LockRowsPath);
+ LockRowsPath *pathnode = makePathNode(root, LockRowsPath);
pathnode->path.pathtype = T_LockRows;
pathnode->path.parent = rel;
@@ -3025,7 +3049,7 @@ create_modifytable_path(PlannerInfo *root, RelOptInfo *rel,
List *rowMarks, OnConflictExpr *onconflict,
int epqParam)
{
- ModifyTablePath *pathnode = makeNode(ModifyTablePath);
+ ModifyTablePath *pathnode = makePathNode(root, ModifyTablePath);
double total_size;
ListCell *lc;
@@ -3120,7 +3144,7 @@ create_limit_path(PlannerInfo *root, RelOptInfo *rel,
Node *limitOffset, Node *limitCount,
int64 offset_est, int64 count_est)
{
- LimitPath *pathnode = makeNode(LimitPath);
+ LimitPath *pathnode = makePathNode(root, LimitPath);
pathnode->path.pathtype = T_Limit;
pathnode->path.parent = rel;
diff --git a/src/include/nodes/relation.h b/src/include/nodes/relation.h
index f7ac6f6..aa2e9b3 100644
--- a/src/include/nodes/relation.h
+++ b/src/include/nodes/relation.h
@@ -128,6 +128,8 @@ typedef struct PlannerGlobal
bool parallelModeNeeded; /* parallel mode actually required? */
char maxParallelHazard; /* worst PROPARALLEL hazard level */
+
+ MemoryContext path_cxt; /* Temporary context for holding paths. */
} PlannerGlobal;
/* macro for fetching the Plan associated with a SubPlan node */
diff --git a/src/include/optimizer/pathnode.h b/src/include/optimizer/pathnode.h
index 53cad24..18591df 100644
--- a/src/include/optimizer/pathnode.h
+++ b/src/include/optimizer/pathnode.h
@@ -62,8 +62,11 @@ extern BitmapOrPath *create_bitmap_or_path(PlannerInfo *root,
List *bitmapquals);
extern TidPath *create_tidscan_path(PlannerInfo *root, RelOptInfo *rel,
List *tidquals, Relids required_outer);
-extern AppendPath *create_append_path(RelOptInfo *rel, List *subpaths,
- Relids required_outer, int parallel_workers);
+extern AppendPath *create_append_path(PlannerInfo *root,
+ RelOptInfo *rel,
+ List *subpaths,
+ Relids required_outer,
+ int parallel_workers);
extern MergeAppendPath *create_merge_append_path(PlannerInfo *root,
RelOptInfo *rel,
List *subpaths,
@@ -71,7 +74,8 @@ extern MergeAppendPath *create_merge_append_path(PlannerInfo *root,
Relids required_outer);
extern ResultPath *create_result_path(PlannerInfo *root, RelOptInfo *rel,
PathTarget *target, List *resconstantqual);
-extern MaterialPath *create_material_path(RelOptInfo *rel, Path *subpath);
+extern MaterialPath *create_material_path(PlannerInfo *root, RelOptInfo *rel,
+ Path *subpath);
extern UniquePath *create_unique_path(PlannerInfo *root, RelOptInfo *rel,
Path *subpath, SpecialJoinInfo *sjinfo);
extern GatherPath *create_gather_path(PlannerInfo *root,
diff --git a/src/include/optimizer/paths.h b/src/include/optimizer/paths.h
index ebda308..733e40d 100644
--- a/src/include/optimizer/paths.h
+++ b/src/include/optimizer/paths.h
@@ -49,7 +49,7 @@ extern PGDLLIMPORT join_search_hook_type join_search_hook;
extern RelOptInfo *make_one_rel(PlannerInfo *root, List *joinlist);
-extern void set_dummy_rel_pathlist(RelOptInfo *rel);
+extern void set_dummy_rel_pathlist(PlannerInfo *root, RelOptInfo *rel);
extern RelOptInfo *standard_join_search(PlannerInfo *root, int levels_needed,
List *initial_rels);
--
1.7.9.5
[application/octet-stream] 0002-Patch-to-measure-memory-used-in-CurrentMemoryContext.patch (3.1K, ../../CAFjFpRem9PpMPXuJNrTTjike1gseRbSWUjJbx=5cD9Qi1egvoQ@mail.gmail.com/3-0002-Patch-to-measure-memory-used-in-CurrentMemoryContext.patch)
download | inline diff:
From f01a67fe92eb5046d208cfa11578fe753562d8e0 Mon Sep 17 00:00:00 2001
From: Ashutosh Bapat <[email protected]>
Date: Wed, 1 Mar 2017 12:12:11 +0530
Subject: [PATCH 2/3] Patch to measure memory used in CurrentMemoryContext in
standard_planner().
---
src/backend/optimizer/plan/planner.c | 5 +++++
src/backend/utils/mmgr/mcxt.c | 26 ++++++++++++++++++++++++++
src/include/utils/memutils.h | 6 ++++++
3 files changed, 37 insertions(+)
diff --git a/src/backend/optimizer/plan/planner.c b/src/backend/optimizer/plan/planner.c
index b74e887..410750d 100644
--- a/src/backend/optimizer/plan/planner.c
+++ b/src/backend/optimizer/plan/planner.c
@@ -195,6 +195,9 @@ standard_planner(Query *parse, int cursorOptions, ParamListInfo boundParams)
Plan *top_plan;
ListCell *lp,
*lr;
+ MemoryContextCounters mem_start;
+
+ MemoryContextFuncStatsStart(CurrentMemoryContext, &mem_start, __FUNCTION__);
/*
* Set up global state for this planner invocation. This data is needed
@@ -425,6 +428,8 @@ standard_planner(Query *parse, int cursorOptions, ParamListInfo boundParams)
MemoryContextResetAndDeleteChildren(glob->path_cxt);
glob->path_cxt = NULL;
+ MemoryContextFuncStatsEnd(CurrentMemoryContext, &mem_start, __FUNCTION__);
+
return result;
}
diff --git a/src/backend/utils/mmgr/mcxt.c b/src/backend/utils/mmgr/mcxt.c
index 6ad0bb4..94b25ac 100644
--- a/src/backend/utils/mmgr/mcxt.c
+++ b/src/backend/utils/mmgr/mcxt.c
@@ -577,6 +577,32 @@ MemoryContextStatsInternal(MemoryContext context, int level,
}
}
+void
+MemoryContextFuncStatsStart(MemoryContext context,
+ MemoryContextCounters *start_counts,
+ const char *label)
+{
+ memset(start_counts, 0, sizeof(*start_counts));
+ MemoryContextStatsInternal(context, 0, false, 100, start_counts);
+}
+
+void
+MemoryContextFuncStatsEnd(MemoryContext context,
+ MemoryContextCounters *start_counts,
+ const char *label)
+{
+ MemoryContextCounters end_counts;
+ Size start_used_space = start_counts->totalspace - start_counts->freespace;
+ Size end_used_space;
+
+ memset(&end_counts, 0, sizeof(end_counts));
+ MemoryContextStatsInternal(context, 0, false, 100, &end_counts);
+ end_used_space = end_counts.totalspace - end_counts.freespace;
+
+ elog(NOTICE, "%s,%s,%zu,%zu,%ld", label, context->name,
+ start_used_space, end_used_space, end_used_space - start_used_space);
+}
+
/*
* MemoryContextCheck
* Check all chunks in the named context.
diff --git a/src/include/utils/memutils.h b/src/include/utils/memutils.h
index 1d1035e..7d605b1 100644
--- a/src/include/utils/memutils.h
+++ b/src/include/utils/memutils.h
@@ -122,6 +122,12 @@ extern MemoryContext MemoryContextCreate(NodeTag tag, Size size,
MemoryContextMethods *methods,
MemoryContext parent,
const char *name);
+extern void MemoryContextFuncStatsStart(MemoryContext context,
+ MemoryContextCounters *start_counts,
+ const char *func_label);
+extern void MemoryContextFuncStatsEnd(MemoryContext context,
+ MemoryContextCounters *start_counts,
+ const char *func_label);
/*
--
1.7.9.5
[application/octet-stream] 0003-GUC-zap_path-to-enable-freeing-memory-consumed-by-pa.patch (2.9K, ../../CAFjFpRem9PpMPXuJNrTTjike1gseRbSWUjJbx=5cD9Qi1egvoQ@mail.gmail.com/4-0003-GUC-zap_path-to-enable-freeing-memory-consumed-by-pa.patch)
download | inline diff:
From 9c863c57c585303f2ba7b5ce4d892c723210b098 Mon Sep 17 00:00:00 2001
From: Ashutosh Bapat <[email protected]>
Date: Wed, 1 Mar 2017 13:29:51 +0530
Subject: [PATCH 3/3] GUC zap_path to enable freeing memory consumed by paths.
For measuring the memory saved, add a GUC zap_path to enable/disable
freeing memory occupied by paths.
---
src/backend/optimizer/path/costsize.c | 1 +
src/backend/optimizer/plan/planner.c | 15 +++++++++------
src/backend/utils/misc/guc.c | 10 ++++++++++
src/include/optimizer/cost.h | 1 +
4 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/src/backend/optimizer/path/costsize.c b/src/backend/optimizer/path/costsize.c
index c138f57..f4dfa00 100644
--- a/src/backend/optimizer/path/costsize.c
+++ b/src/backend/optimizer/path/costsize.c
@@ -126,6 +126,7 @@ bool enable_nestloop = true;
bool enable_material = true;
bool enable_mergejoin = true;
bool enable_hashjoin = true;
+bool zap_paths = true;
typedef struct
{
diff --git a/src/backend/optimizer/plan/planner.c b/src/backend/optimizer/plan/planner.c
index 410750d..c7b085f 100644
--- a/src/backend/optimizer/plan/planner.c
+++ b/src/backend/optimizer/plan/planner.c
@@ -421,12 +421,15 @@ standard_planner(Query *parse, int cursorOptions, ParamListInfo boundParams)
result->stmt_location = parse->stmt_location;
result->stmt_len = parse->stmt_len;
- /*
- * We do not need paths any more, blow those away.
- * TODO: probably we should also set the pathlists to NIL.
- */
- MemoryContextResetAndDeleteChildren(glob->path_cxt);
- glob->path_cxt = NULL;
+ if (zap_paths)
+ {
+ /*
+ * We do not need paths any more, blow those away.
+ * TODO: probably we should also set the pathlists to NIL.
+ */
+ MemoryContextResetAndDeleteChildren(glob->path_cxt);
+ glob->path_cxt = NULL;
+ }
MemoryContextFuncStatsEnd(CurrentMemoryContext, &mem_start, __FUNCTION__);
diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c
index 2477138..630d3f7 100644
--- a/src/backend/utils/misc/guc.c
+++ b/src/backend/utils/misc/guc.c
@@ -912,6 +912,16 @@ static struct config_bool ConfigureNamesBool[] =
true,
NULL, NULL, NULL
},
+
+ {
+ {"zap_paths", PGC_USERSET, QUERY_TUNING_GEQO,
+ gettext_noop("Free up the memory used by paths at the end of planning."),
+ },
+ &zap_paths,
+ true,
+ NULL, NULL, NULL
+ },
+
{
/* Not for general use --- used by SET SESSION AUTHORIZATION */
{"is_superuser", PGC_INTERNAL, UNGROUPED,
diff --git a/src/include/optimizer/cost.h b/src/include/optimizer/cost.h
index 72200fa..fc882ad 100644
--- a/src/include/optimizer/cost.h
+++ b/src/include/optimizer/cost.h
@@ -67,6 +67,7 @@ extern bool enable_material;
extern bool enable_mergejoin;
extern bool enable_hashjoin;
extern int constraint_exclusion;
+extern bool zap_paths;
extern double clamp_row_est(double nrows);
extern double index_pages_fetched(double tuples_fetched, BlockNumber pages,
--
1.7.9.5
^ permalink raw reply [nested|flat] 277+ messages in thread
* Re: Partition-wise join for join between (declaratively) partitioned tables
2017-03-01 08:56 Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
@ 2017-03-09 01:14 ` Robert Haas <[email protected]>
2017-03-10 10:43 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
1 sibling, 1 reply; 277+ messages in thread
From: Robert Haas @ 2017-03-09 01:14 UTC (permalink / raw)
To: Ashutosh Bapat <[email protected]>; +Cc: Rajkumar Raghuwanshi <[email protected]>; pgsql-hackers
On Wed, Mar 1, 2017 at 3:56 AM, Ashutosh Bapat
<[email protected]> wrote:
>> 2. If the PartitionJoinPath emerges as the best path, we create paths
>> for each of the remaining child-joins. Then we collect paths with
>> properties same as the given PartitionJoinPath, one from each
>> child-join. These paths are converted into plans and a Merge/Append
>> plan is created combing these plans. The paths and plans for
>> child-join are created in a temporary memory context. The final plan
>> for each child-join is copied into planner's context and the temporary
>> memory context is reset.
>>
>
> Robert and I discussed this in more detail. Path creation code may
> allocate objects other than paths. postgres_fdw, for example,
> allocates character array to hold the name of relation being
> pushed-down. When the temporary context gets zapped after creating
> paths for a given child-join, those other objects also gets thrown
> away. Attached patch has implemented the idea that came out of the
> discussion.
>
> We create a memory context for holding paths at the time of creating
> PlannerGlobal and save it in PlannerGlobal. The patch introduces a new
> macro makePathNode() which allocates the memory for given type of path
> from this context. Every create_*_path function has been changed to
> use this macro instead of makeNode(). In standard_planner(), at the
> end of planning we destroy the memory context freeing all the paths
> allocated. While creating a plan node, planner copies everything
> required by the plan from the path, so the path is not needed any
> more. So, freeing corresponding memory should not have any adverse
> effects.
>
> Most of the create_*_path() functions accept root as an argument, thus
> the temporary path context is available through root->glob everywhere.
> An exception is create_append_path() which does not accept root as an
> argument. The patch changes create_append_path() and its callers like
> set_dummy_rel_pathlist(), mark_dummy_rel() to accept root as an
> argument. Ideally paths are not required after creating plan, so we
> should be
> able to free the context right after the call to create_plan(). But we
> need dummy paths while creating flat rtable in
> set_plan_references()->add_rtes_to_flat_rtable(). We used to So free
> the path context at the end of planning cycle. Now that we are
> allocating all the paths in a different memory context, it doesn't
> make sense to switch context in mark_dummy_rel().
>
> 0001 patch implements the idea described above.
> 0002 patch adds instrumentation to measure memory consumed in
> standard_planner() call.
> 0003 patch adds a GUC zap_paths to enable/disable destroying path context.
> The last two patches are for testing only.
>
> Attached also find the SQL script and its output showing the memory
> saved. For a 5 way self-join of pg_class, the total memory consumed in
> standard_planner() is 760K without patch and with patch it comes down
> to 713K, saving 47K memory otherwise occupied by paths. It looks like
> something useful even without partition-wise joins.
Of course, that's not a lot, but the savings will be a lot better for
partition-wise joins. Do you have a set of patches for that feature
that apply on top of 0001?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 277+ messages in thread
* Re: Partition-wise join for join between (declaratively) partitioned tables
2017-03-01 08:56 Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-09 01:14 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
@ 2017-03-10 10:43 ` Ashutosh Bapat <[email protected]>
2017-03-13 19:24 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
0 siblings, 1 reply; 277+ messages in thread
From: Ashutosh Bapat @ 2017-03-10 10:43 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: Rajkumar Raghuwanshi <[email protected]>; pgsql-hackers
PFA the zip containing all the patches rebased on
56018bf26eec1a0b4bf20303c98065a8eb1b0c5d and contain the patch to free
memory consumed by paths using a separate path context.
There are some more changes wrt earlier set of patches
1. Since we don't need a separate context for planning for each
child_join, changed code in create_partition_join_plan() to not do
that. The function collects all child_join paths into merge/append
path and calls create_plan_recurse() on that path instead of
converting each child_join path to plan one at a time.
2. Changed optimizer/README and some comments referring to temporary
memory context, since we do not use that anymore.
3. reparameterize_path_by_child() is fixed to translate the merge and
hash clause in Hash/Merge path.
On Thu, Mar 9, 2017 at 6:44 AM, Robert Haas <[email protected]> wrote:
> On Wed, Mar 1, 2017 at 3:56 AM, Ashutosh Bapat
> <[email protected]> wrote:
>>> 2. If the PartitionJoinPath emerges as the best path, we create paths
>>> for each of the remaining child-joins. Then we collect paths with
>>> properties same as the given PartitionJoinPath, one from each
>>> child-join. These paths are converted into plans and a Merge/Append
>>> plan is created combing these plans. The paths and plans for
>>> child-join are created in a temporary memory context. The final plan
>>> for each child-join is copied into planner's context and the temporary
>>> memory context is reset.
>>>
>>
>> Robert and I discussed this in more detail. Path creation code may
>> allocate objects other than paths. postgres_fdw, for example,
>> allocates character array to hold the name of relation being
>> pushed-down. When the temporary context gets zapped after creating
>> paths for a given child-join, those other objects also gets thrown
>> away. Attached patch has implemented the idea that came out of the
>> discussion.
>>
>> We create a memory context for holding paths at the time of creating
>> PlannerGlobal and save it in PlannerGlobal. The patch introduces a new
>> macro makePathNode() which allocates the memory for given type of path
>> from this context. Every create_*_path function has been changed to
>> use this macro instead of makeNode(). In standard_planner(), at the
>> end of planning we destroy the memory context freeing all the paths
>> allocated. While creating a plan node, planner copies everything
>> required by the plan from the path, so the path is not needed any
>> more. So, freeing corresponding memory should not have any adverse
>> effects.
>>
>> Most of the create_*_path() functions accept root as an argument, thus
>> the temporary path context is available through root->glob everywhere.
>> An exception is create_append_path() which does not accept root as an
>> argument. The patch changes create_append_path() and its callers like
>> set_dummy_rel_pathlist(), mark_dummy_rel() to accept root as an
>> argument. Ideally paths are not required after creating plan, so we
>> should be
>> able to free the context right after the call to create_plan(). But we
>> need dummy paths while creating flat rtable in
>> set_plan_references()->add_rtes_to_flat_rtable(). We used to So free
>> the path context at the end of planning cycle. Now that we are
>> allocating all the paths in a different memory context, it doesn't
>> make sense to switch context in mark_dummy_rel().
>>
>> 0001 patch implements the idea described above.
>> 0002 patch adds instrumentation to measure memory consumed in
>> standard_planner() call.
>> 0003 patch adds a GUC zap_paths to enable/disable destroying path context.
>> The last two patches are for testing only.
>>
>> Attached also find the SQL script and its output showing the memory
>> saved. For a 5 way self-join of pg_class, the total memory consumed in
>> standard_planner() is 760K without patch and with patch it comes down
>> to 713K, saving 47K memory otherwise occupied by paths. It looks like
>> something useful even without partition-wise joins.
>
> Of course, that's not a lot, but the savings will be a lot better for
> partition-wise joins. Do you have a set of patches for that feature
> that apply on top of 0001?
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Attachments:
[application/zip] pg_dp_join_patches_v2.zip (89.8K, ../../CAFjFpRfqotRR6cM3sooBHMHEVdkFfAZ6PyYg4GRZsoMuW08HjQ@mail.gmail.com/2-pg_dp_join_patches_v2.zip)
download
^ permalink raw reply [nested|flat] 277+ messages in thread
* Re: Partition-wise join for join between (declaratively) partitioned tables
2017-03-01 08:56 Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-09 01:14 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-10 10:43 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
@ 2017-03-13 19:24 ` Robert Haas <[email protected]>
2017-03-14 00:17 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-14 12:04 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
0 siblings, 2 replies; 277+ messages in thread
From: Robert Haas @ 2017-03-13 19:24 UTC (permalink / raw)
To: Ashutosh Bapat <[email protected]>; +Cc: Rajkumar Raghuwanshi <[email protected]>; pgsql-hackers
On Fri, Mar 10, 2017 at 5:43 AM, Ashutosh Bapat
<[email protected]> wrote:
> PFA the zip containing all the patches rebased on
> 56018bf26eec1a0b4bf20303c98065a8eb1b0c5d and contain the patch to free
> memory consumed by paths using a separate path context.
Some very high-level thoughts based on a look through these patches:
In 0001, you've removed a comment about how GEQO needs special
handling, but it doesn't look as if you've made any compensating
change elsewhere. That seems unlikely to be correct. If GEQO needs
some paths to survive longer than others, how can it be right for this
code to create them all in the same context? Incidentally,
geqo_eval() seems to be an existing precedent for the idea of throwing
away paths and RelOptInfos, so we might want to use similar code for
partitionwise join.
0002 and 0003 look OK.
Probably 0004 is OK too, although that seems to be adding some
overhead to existing callers for the benefit of new ones. Might be
insignificant, though.
0005 looks OK, except that add_join_rel's definition is missing a
"static" qualifier. That's not just cosmetic; based on previous
expereince, this will break the BF.
0006 seems to be unnecessary; the new function isn't used in later patches.
Haven't looked at 0007 yet.
0008 is, as previously mentioned, more than we probably want to commit.
Haven't looked at 0009 yet.
0010 - 0012 seem to be various fixes which would need to be done
before or along with 0009, rather than afterward, so I am confused
about the ordering of those patches in the patch series.
The commit message for 0013 is a bit unclear about what it's doing,
although I can guess, a bit, based on the commit message for 0007.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 277+ messages in thread
* Re: Partition-wise join for join between (declaratively) partitioned tables
2017-03-01 08:56 Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-09 01:14 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-10 10:43 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-13 19:24 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
@ 2017-03-14 00:17 ` Robert Haas <[email protected]>
2017-03-14 00:58 ` Re: Partition-wise join for join between (declaratively) partitioned tables Amit Langote <[email protected]>
2017-03-14 12:04 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
1 sibling, 2 replies; 277+ messages in thread
From: Robert Haas @ 2017-03-14 00:17 UTC (permalink / raw)
To: Ashutosh Bapat <[email protected]>; +Cc: Rajkumar Raghuwanshi <[email protected]>; pgsql-hackers
On Mon, Mar 13, 2017 at 3:24 PM, Robert Haas <[email protected]> wrote:
> Haven't looked at 0007 yet.
+ if (rel->part_scheme)
+ {
+ int cnt_parts;
+
+ for (cnt_parts = 0; cnt_parts < nparts; cnt_parts++)
+ {
+ if (rel->part_oids[cnt_parts] ==
childRTE->relid)
+ {
+ Assert(!rel->part_rels[cnt_parts]);
+ rel->part_rels[cnt_parts] = childrel;
+ }
+ }
+ }
It's not very appealing to use an O(n^2) algorithm here. I wonder if
we could arrange things so that inheritance expansion expands
partitions in the right order, and then we could just match them up
one-to-one. This would probably require an alternate version of
find_all_inheritors() that expand_inherited_rtentry() would call only
for partitioned tables. Failing that, another idea would be to use
qsort() or qsort_arg() to put the partitions in the right order.
+ if (relation->rd_rel->relkind != RELKIND_PARTITIONED_TABLE ||
+ !inhparent ||
+ !(rel->part_scheme = find_partition_scheme(root, relation)))
Maybe just don't call this function in the first place in the
!inhparent case, instead of passing down an argument that must always
be true.
+ /* Match the partition key types. */
+ for (cnt_pks = 0; cnt_pks < partnatts; cnt_pks++)
+ {
+ /*
+ * For types, it suffices to match the type
id, mod and collation;
+ * len, byval and align are depedent on the first two.
+ */
+ if (part_key->partopfamily[cnt_pks] !=
part_scheme->partopfamily[cnt_pks] ||
+ part_key->partopcintype[cnt_pks] !=
part_scheme->partopcintype[cnt_pks] ||
+ part_key->parttypid[cnt_pks] !=
part_scheme->key_types[cnt_pks] ||
+ part_key->parttypmod[cnt_pks] !=
part_scheme->key_typmods[cnt_pks] ||
+ part_key->parttypcoll[cnt_pks] !=
part_scheme->key_collations[cnt_pks])
+ break;
+ }
I think memcmp() might be better than a for-loop.
Overall this one looks pretty good and straightforward. Of course, I
haven't looked at the main act (0009) yet.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 277+ messages in thread
* Re: Partition-wise join for join between (declaratively) partitioned tables
2017-03-01 08:56 Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-09 01:14 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-10 10:43 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-13 19:24 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-14 00:17 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
@ 2017-03-14 00:58 ` Amit Langote <[email protected]>
2017-03-14 12:04 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
1 sibling, 1 reply; 277+ messages in thread
From: Amit Langote @ 2017-03-14 00:58 UTC (permalink / raw)
To: Robert Haas <[email protected]>; Ashutosh Bapat <[email protected]>; +Cc: Rajkumar Raghuwanshi <[email protected]>; pgsql-hackers
On 2017/03/14 9:17, Robert Haas wrote:
> On Mon, Mar 13, 2017 at 3:24 PM, Robert Haas <[email protected]> wrote:
>> Haven't looked at 0007 yet.
>
> Overall this one looks pretty good and straightforward.
In the following code of find_partition_scheme():
+ /* Did not find matching partition scheme. Create one. */
+ part_scheme = (PartitionScheme) palloc0(sizeof(PartitionSchemeData));
+
+ /* Copy partition bounds/lists. */
+ part_scheme->nparts = part_desc->nparts;
+ part_scheme->strategy = part_key->strategy;
+ part_scheme->boundinfo = part_desc->boundinfo;
+
+ /* Store partition key information. */
+ part_scheme->partnatts = part_key->partnatts;
+
+ part_scheme->partopfamily = (Oid *) palloc(sizeof(Oid) * partnatts);
+ memcpy(part_scheme->partopfamily, part_key->partopfamily,
+ sizeof(Oid) * partnatts);
+
+ part_scheme->partopcintype = (Oid *) palloc(sizeof(Oid) * partnatts);
+ memcpy(part_scheme->partopcintype, part_key->partopcintype,
+ sizeof(Oid) * partnatts);
+
+ part_scheme->key_types = (Oid *) palloc(sizeof(Oid) * partnatts);
+ memcpy(part_scheme->key_types, part_key->parttypid,
+ sizeof(Oid) * partnatts);
+
+ part_scheme->key_typmods = (int32 *) palloc(sizeof(int32) * partnatts);
+ memcpy(part_scheme->key_typmods, part_key->parttypmod,
+ sizeof(int32) * partnatts);
+
+ part_scheme->key_collations = (Oid *) palloc(sizeof(Oid) * partnatts);
+ memcpy(part_scheme->key_collations, part_key->parttypcoll,
+ sizeof(Oid) * partnatts);
Couldn't we avoid the memcpy() on individual members of part_key? After
all, RelationData.rd_partkey is guarded just like rd_partdesc by
relcache.c in face of invalidations (see keep_partkey logic in
RelationClearRelation).
Thanks,
Amit
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 277+ messages in thread
* Re: Partition-wise join for join between (declaratively) partitioned tables
2017-03-01 08:56 Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-09 01:14 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-10 10:43 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-13 19:24 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-14 00:17 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-14 00:58 ` Re: Partition-wise join for join between (declaratively) partitioned tables Amit Langote <[email protected]>
@ 2017-03-14 12:04 ` Ashutosh Bapat <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Ashutosh Bapat @ 2017-03-14 12:04 UTC (permalink / raw)
To: Amit Langote <[email protected]>; +Cc: Robert Haas <[email protected]>; Rajkumar Raghuwanshi <[email protected]>; pgsql-hackers
On Tue, Mar 14, 2017 at 6:28 AM, Amit Langote
<[email protected]> wrote:
> On 2017/03/14 9:17, Robert Haas wrote:
>> On Mon, Mar 13, 2017 at 3:24 PM, Robert Haas <[email protected]> wrote:
>>> Haven't looked at 0007 yet.
>>
>> Overall this one looks pretty good and straightforward.
>
> In the following code of find_partition_scheme():
>
> + /* Did not find matching partition scheme. Create one. */
> + part_scheme = (PartitionScheme) palloc0(sizeof(PartitionSchemeData));
> +
> + /* Copy partition bounds/lists. */
> + part_scheme->nparts = part_desc->nparts;
> + part_scheme->strategy = part_key->strategy;
> + part_scheme->boundinfo = part_desc->boundinfo;
> +
> + /* Store partition key information. */
> + part_scheme->partnatts = part_key->partnatts;
> +
> + part_scheme->partopfamily = (Oid *) palloc(sizeof(Oid) * partnatts);
> + memcpy(part_scheme->partopfamily, part_key->partopfamily,
> + sizeof(Oid) * partnatts);
> +
> + part_scheme->partopcintype = (Oid *) palloc(sizeof(Oid) * partnatts);
> + memcpy(part_scheme->partopcintype, part_key->partopcintype,
> + sizeof(Oid) * partnatts);
> +
> + part_scheme->key_types = (Oid *) palloc(sizeof(Oid) * partnatts);
> + memcpy(part_scheme->key_types, part_key->parttypid,
> + sizeof(Oid) * partnatts);
> +
> + part_scheme->key_typmods = (int32 *) palloc(sizeof(int32) * partnatts);
> + memcpy(part_scheme->key_typmods, part_key->parttypmod,
> + sizeof(int32) * partnatts);
> +
> + part_scheme->key_collations = (Oid *) palloc(sizeof(Oid) * partnatts);
> + memcpy(part_scheme->key_collations, part_key->parttypcoll,
> + sizeof(Oid) * partnatts);
>
> Couldn't we avoid the memcpy() on individual members of part_key? After
> all, RelationData.rd_partkey is guarded just like rd_partdesc by
> relcache.c in face of invalidations (see keep_partkey logic in
> RelationClearRelation).
This suggestion looks good to me. Incorporated in the latest set of patches.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 277+ messages in thread
* Re: Partition-wise join for join between (declaratively) partitioned tables
2017-03-01 08:56 Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-09 01:14 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-10 10:43 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-13 19:24 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-14 00:17 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
@ 2017-03-14 12:04 ` Ashutosh Bapat <[email protected]>
1 sibling, 0 replies; 277+ messages in thread
From: Ashutosh Bapat @ 2017-03-14 12:04 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: Rajkumar Raghuwanshi <[email protected]>; pgsql-hackers
On Tue, Mar 14, 2017 at 5:47 AM, Robert Haas <[email protected]> wrote:
> On Mon, Mar 13, 2017 at 3:24 PM, Robert Haas <[email protected]> wrote:
>> Haven't looked at 0007 yet.
>
> + if (rel->part_scheme)
> + {
> + int cnt_parts;
> +
> + for (cnt_parts = 0; cnt_parts < nparts; cnt_parts++)
> + {
> + if (rel->part_oids[cnt_parts] ==
> childRTE->relid)
> + {
> + Assert(!rel->part_rels[cnt_parts]);
> + rel->part_rels[cnt_parts] = childrel;
> + }
> + }
> + }
>
> It's not very appealing to use an O(n^2) algorithm here. I wonder if
> we could arrange things so that inheritance expansion expands
> partitions in the right order, and then we could just match them up
> one-to-one. This would probably require an alternate version of
> find_all_inheritors() that expand_inherited_rtentry() would call only
> for partitioned tables.
That seems a much better solution, but
1. Right now when we expand a multi-level partitioned table, we
include indirect partitions as direct children in inheritance
hierachy. part_rels array OTOH should correspond to the partitioning
scheme and should hold RelOptInfos of direct partitions. 0013 patch
fixes that to include only direct partitions as direct children
preserving partitioning hierarchy in the inheritance hierarchy. That
patch right now uses find_inheritance_children() to get Oids of direct
partitions, but instead it could return rd_partdesc->oids in the form
of list; OIDs ordered same as the array. Once we do that, we should
expect the appinfos to appear in the same order as the
rd_partdesc->oids and so RelOptInfo::part_oids. We just need to make
sure that the order is preserved and assign part_rels as they appear
in that loop.
One would argue that we preserve the OIDs only for single-level
partitioned tables, but in expand_inheritance_rtentry(), if we want to
detect whether a relation is single-level partitioned or multi-level,
we need to look up its direct partitions to see if they are further
partitioned. That will look a bit ugly and will not be necessary once
we have 0013. In case we decide to defer multi-level partitioned table
changes to v11 and based on the progress in [1], I will work on fixing
the order in which appinfos are created for single-level partitioned
tables.
> Failing that, another idea would be to use
> qsort() or qsort_arg() to put the partitions in the right order.
I didn't get this. I could not find documentation for qsort_arg(). Can
you please elaborate? I guess, if we fix expand_inheritance_rtentry()
we don't need this. It looks like we will change
expand_inheritance_rtentry() anyway.
>
> + if (relation->rd_rel->relkind != RELKIND_PARTITIONED_TABLE ||
> + !inhparent ||
> + !(rel->part_scheme = find_partition_scheme(root, relation)))
>
> Maybe just don't call this function in the first place in the
> !inhparent case, instead of passing down an argument that must always
> be true.
The function serves a single place to re/set partitioning information.
It would set the partitioning information if the above three
conditions are met. Otherwise it would nullify that information. If we
decide not to call this function when !inhparent, we will need to
nullify the partitioning information outside of this function as well
as inside this function, duplicating the code.
>
> + /* Match the partition key types. */
> + for (cnt_pks = 0; cnt_pks < partnatts; cnt_pks++)
> + {
> + /*
> + * For types, it suffices to match the type
> id, mod and collation;
> + * len, byval and align are depedent on the first two.
> + */
> + if (part_key->partopfamily[cnt_pks] !=
> part_scheme->partopfamily[cnt_pks] ||
> + part_key->partopcintype[cnt_pks] !=
> part_scheme->partopcintype[cnt_pks] ||
> + part_key->parttypid[cnt_pks] !=
> part_scheme->key_types[cnt_pks] ||
> + part_key->parttypmod[cnt_pks] !=
> part_scheme->key_typmods[cnt_pks] ||
> + part_key->parttypcoll[cnt_pks] !=
> part_scheme->key_collations[cnt_pks])
> + break;
> + }
>
> I think memcmp() might be better than a for-loop.
Done.
PFA patches.
[1] https://www.postgresql.org/message-id/[email protected]
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Attachments:
[application/zip] pg_dp_join_patches_v3.zip (89.4K, ../../CAFjFpRf4wXhQeKhi4NhA9B3vo8BK99zkm-o8tEBq3qb8cwbLzQ@mail.gmail.com/2-pg_dp_join_patches_v3.zip)
download
^ permalink raw reply [nested|flat] 277+ messages in thread
* Re: Partition-wise join for join between (declaratively) partitioned tables
2017-03-01 08:56 Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-09 01:14 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-10 10:43 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-13 19:24 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
@ 2017-03-14 12:04 ` Ashutosh Bapat <[email protected]>
2017-03-15 00:33 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
1 sibling, 1 reply; 277+ messages in thread
From: Ashutosh Bapat @ 2017-03-14 12:04 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: Rajkumar Raghuwanshi <[email protected]>; pgsql-hackers
Thanks for the review.
>
> Some very high-level thoughts based on a look through these patches:
>
> In 0001, you've removed a comment about how GEQO needs special
> handling, but it doesn't look as if you've made any compensating
> change elsewhere. That seems unlikely to be correct. If GEQO needs
> some paths to survive longer than others, how can it be right for this
> code to create them all in the same context?
Thanks for pointing that out. I have replaced the code and the
comments back. There was another issue that the temporary paths
created by geqo will not be freed when geqo moves one genetic string
to next genetic string (or what it calls as tour: an list of relation
to be joined in a given order). To fix this, we need to set the path
context to the temporary context of geqo inside geqo_eval() before
calling gimme_tree() and reset it later. That way the temporary paths
are also created in the temporary memory context of geqo. Fixed in the
patch.
> Incidentally,
> geqo_eval() seems to be an existing precedent for the idea of throwing
> away paths and RelOptInfos, so we might want to use similar code for
> partitionwise join.
There are some differences in what geqo does and what partition-wise
needs to do. geqo tries many joining orders each one in a separate
temporary context. The way geqo slices the work, every slice produces
a full plan. For partition-wise join I do not see a way to slice the
work such that the whole path and corresponding RelOptInfos come from
the same slice. So, we can't use the same method as GEQO.
It's worth noticing that paths are created twice for the cheapest
joining order that it finds: once in the trial phase and second time
when the final plan is created. The second time, the paths,
RelOptInfos, expressions used by the final plan are in the context as
the plan.
>
> 0002 and 0003 look OK.
>
> Probably 0004 is OK too, although that seems to be adding some
> overhead to existing callers for the benefit of new ones. Might be
> insignificant, though.
Yes, the overhead is to add and extract the appinfo from a list when
there is only one appinfo. We may optimize it by passing appinfo
directly when there's only one and pass list when there are more, but
that is complicating the code unnecessarily. The overhead seems to be
worth the cost to keep the code simpler.
>
> 0005 looks OK, except that add_join_rel's definition is missing a
> "static" qualifier. That's not just cosmetic; based on previous
> expereince, this will break the BF.
Thanks for pointing it out. Done.
>
> 0006 seems to be unnecessary; the new function isn't used in later patches.
It's required by 0011 - reparameterize_path_by_child(). BTW, I need to
know whether reparameterize_path_by_child() looks good, so that I can
complete it by adding support for all kinds of path in that function.
>
> Haven't looked at 0007 yet.
>
> 0008 is, as previously mentioned, more than we probably want to commit.
I agree, and I will work on that.
>
> Haven't looked at 0009 yet.
>
> 0010 - 0012 seem to be various fixes which would need to be done
> before or along with 0009, rather than afterward, so I am confused
> about the ordering of those patches in the patch series.
They are needed only when we have 0009. But when those are clubbed
with 0009, it makes 0009 review difficult as the code for those fixes
mixes with the code for partition-wise support. So, I have separated
those out into patches categorized by functionality. Reviewer may then
apply 0009 and see what failures each of the changes in 0010-0012
fixes, if required. They need to be committed along-with 0009.
>
> The commit message for 0013 is a bit unclear about what it's doing,
> although I can guess, a bit, based on the commit message for 0007.
>
This is preparatory patch for 0015 which supports partition-wise join
for multi-level partitioned tables. We have discussed about
partition-wise join support for multi-level partitioned tables in [1].
We may decide to postpone patches 0013-0015 to v11, if this gets too
much for v10.
[1] https://www.postgresql.org/message-id/CAFjFpRceMmx26653XFAYvc5KVQcrzcKScVFqZdbXV%[email protected]...
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 277+ messages in thread
* Re: Partition-wise join for join between (declaratively) partitioned tables
2017-03-01 08:56 Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-09 01:14 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-10 10:43 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-13 19:24 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-14 12:04 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
@ 2017-03-15 00:33 ` Robert Haas <[email protected]>
2017-03-15 01:21 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-15 12:49 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
0 siblings, 2 replies; 277+ messages in thread
From: Robert Haas @ 2017-03-15 00:33 UTC (permalink / raw)
To: Ashutosh Bapat <[email protected]>; +Cc: Rajkumar Raghuwanshi <[email protected]>; pgsql-hackers
On Tue, Mar 14, 2017 at 8:04 AM, Ashutosh Bapat
<[email protected]> wrote:
>> In 0001, you've removed a comment about how GEQO needs special
>> handling, but it doesn't look as if you've made any compensating
>> change elsewhere. That seems unlikely to be correct. If GEQO needs
>> some paths to survive longer than others, how can it be right for this
>> code to create them all in the same context?
>
> Thanks for pointing that out. I have replaced the code and the
> comments back. There was another issue that the temporary paths
> created by geqo will not be freed when geqo moves one genetic string
> to next genetic string (or what it calls as tour: an list of relation
> to be joined in a given order). To fix this, we need to set the path
> context to the temporary context of geqo inside geqo_eval() before
> calling gimme_tree() and reset it later. That way the temporary paths
> are also created in the temporary memory context of geqo. Fixed in the
> patch.
Yeah, that looks better.
>> Incidentally,
>> geqo_eval() seems to be an existing precedent for the idea of throwing
>> away paths and RelOptInfos, so we might want to use similar code for
>> partitionwise join.
>
> There are some differences in what geqo does and what partition-wise
> needs to do. geqo tries many joining orders each one in a separate
> temporary context. The way geqo slices the work, every slice produces
> a full plan. For partition-wise join I do not see a way to slice the
> work such that the whole path and corresponding RelOptInfos come from
> the same slice. So, we can't use the same method as GEQO.
What I was thinking about was the use of this technique for getting
rid of joinrels:
root->join_rel_list = list_truncate(root->join_rel_list,
savelength);
root->join_rel_hash = savehash;
makePathNode() serves to segregate paths into a separate memory
context that can then be destroyed, but as you point out, the path
lists are still hanging around, and so are the RelOptInfo nodes. It
seems to me we could do a lot better using this technique. Suppose we
jigger things so that the List objects created by add_path go into
path_cxt, and so that RelOptInfo nodes also go into path_cxt. Then
when we blow up path_cxt we won't have dangling pointers in the
RelOptInfo objects any more because the RelOptInfos themselves will be
gone. The only problem is that the join_rel_list (and join_rel_hash
if it exists) will be corrupt, but we can fix that using the technique
demonstrated above.
Of course, that supposes that 0009 can manage to postpone creating
non-sampled child joinrels until create_partition_join_plan(), which
it currently doesn't. In fact, unless I'm missing something, 0009
hasn't been even slightly adapted to take advantage of the
infrastructure in 0001; it doesn't seem to reset the path_cxt or
anything. That seems like a fairly major omission.
Incidentally, I committed 0002, 0003, and 0005 as a single commit with
a few tweaks; I think you may need to do a bit of rebasing.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 277+ messages in thread
* Re: Partition-wise join for join between (declaratively) partitioned tables
2017-03-01 08:56 Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-09 01:14 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-10 10:43 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-13 19:24 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-14 12:04 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 00:33 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
@ 2017-03-15 01:21 ` Robert Haas <[email protected]>
2017-03-15 12:55 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
1 sibling, 1 reply; 277+ messages in thread
From: Robert Haas @ 2017-03-15 01:21 UTC (permalink / raw)
To: Ashutosh Bapat <[email protected]>; +Cc: Rajkumar Raghuwanshi <[email protected]>; pgsql-hackers
On Tue, Mar 14, 2017 at 8:33 PM, Robert Haas <[email protected]> wrote:
> Of course, that supposes that 0009 can manage to postpone creating
> non-sampled child joinrels until create_partition_join_plan(), which
> it currently doesn't. In fact, unless I'm missing something, 0009
> hasn't been even slightly adapted to take advantage of the
> infrastructure in 0001; it doesn't seem to reset the path_cxt or
> anything. That seems like a fairly major omission.
Some other comments on 0009:
Documentation changes for the new GUCs are missing.
+between the partition keys of the joining tables. The equi-join between
+partition keys implies that for a given row in a given partition of a given
+partitioned table, its joining row, if exists, should exist only in the
+matching partition of the other partitioned table; no row from non-matching
There could be more than one. I'd write: The equi-join between
partition keys implies that all join partners for a given row in one
partitioned table must be in the corresponding partition of the other
partitioned table.
+#include "miscadmin.h"
#include <limits.h>
#include <math.h>
Added in wrong place.
+ * System attributes do not need
translation. In such a case,
+ * the attribute numbers of the parent
and the child should
+ * start from the same minimum attribute.
I would delete the second sentence and add an Assert() to that effect instead.
+ /* Pass top parent's relids down the inheritance hierarchy. */
Why?
+ for (attno = rel->min_attr; attno <=
rel->max_attr; attno++)
Add add a comment explaining why we need to do this.
- add_paths_to_append_rel(root, rel, live_childrels);
+ add_paths_to_append_rel(root, rel, live_childrels, false);
}
-
No need to remove blank line.
+ * When called on partitioned join relation with partition_join_path = true, it
+ * adds PartitionJoinPath instead of Merge/Append path. This path is costed
+ * based on the costs of sampled child-join and is expanded later into
+ * Merge/Append plan.
I'm not a big fan of the Merge/Append terminology here. If somebody
adds another kind of append-path someday, then all of these comments
will have to be updated. I think this can be phrased more
generically.
/*
+ * While creating PartitionJoinPath, we sample paths from only
a few child
+ * relations. Even if all of sampled children have partial
paths, it's not
+ * guaranteed that all the unsampled children will have partial paths.
+ * Hence we do not create partial PartitionJoinPaths.
+ */
Very sad. I guess if we had parallel append available, we could maybe
dodge this problem, but for now I suppose we're stuck with it.
+ /*
+ * Partitioning scheme in join relation indicates a possibility that the
+ * join may be partitioned, but it's not necessary that every pair of
+ * joining relations can use partition-wise join technique. If one of
+ * joining relations turns out to be unpartitioned, this pair of joining
+ * relations can not use partition-wise join technique.
+ */
+ if (!rel1->part_scheme || !rel2->part_scheme)
+ return;
How can this happen? If rel->part_scheme != NULL, doesn't that imply
that every rel covered by the joinrel is partitioned that way, and
therefore this condition must necessarily hold?
In general, I think it's better style to write explicit tests against
NULL or NIL than to just write if (blahptr).
+ partitioned_join->sjinfo = copyObject(parent_sjinfo);
Why do we need to copy it?
+ /*
+ * Remove the relabel decoration. We can assume that there is
at most one
+ * RelabelType node; eval_const_expressions() simplifies multiple
+ * RelabelType nodes into one.
+ */
+ if (IsA(expr, RelabelType))
+ expr = (Expr *) ((RelabelType *) expr)->arg;
Still, instead of assuming this, you could just s/if/while/, and then
you wouldn't need the assumption any more. Also, consider castNode().
partition_wise_plan_weight may be useful for testing, but I don't
think it should be present in the final patch.
This is not a full review; I ran out of mental energy before I got to
the end. (Sorry.)
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 277+ messages in thread
* Re: Partition-wise join for join between (declaratively) partitioned tables
2017-03-01 08:56 Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-09 01:14 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-10 10:43 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-13 19:24 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-14 12:04 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 00:33 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-15 01:21 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
@ 2017-03-15 12:55 ` Ashutosh Bapat <[email protected]>
2017-03-15 19:05 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
0 siblings, 1 reply; 277+ messages in thread
From: Ashutosh Bapat @ 2017-03-15 12:55 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: Rajkumar Raghuwanshi <[email protected]>; pgsql-hackers
On Wed, Mar 15, 2017 at 6:51 AM, Robert Haas <[email protected]> wrote:
> On Tue, Mar 14, 2017 at 8:33 PM, Robert Haas <[email protected]> wrote:
>> Of course, that supposes that 0009 can manage to postpone creating
>> non-sampled child joinrels until create_partition_join_plan(), which
>> it currently doesn't. In fact, unless I'm missing something, 0009
>> hasn't been even slightly adapted to take advantage of the
>> infrastructure in 0001; it doesn't seem to reset the path_cxt or
>> anything. That seems like a fairly major omission.
>
> Some other comments on 0009:
>
> Documentation changes for the new GUCs are missing.
Done. The description might need more massaging, but I will work on
that once we have fixed their names and usage. I think
sample_partition_fraction and partition_wise_plan_weight, if retained,
will be applicable to other partition-wise planning like
partition-wise aggregates. So we will need more generic description
there.
>
> +between the partition keys of the joining tables. The equi-join between
> +partition keys implies that for a given row in a given partition of a given
> +partitioned table, its joining row, if exists, should exist only in the
> +matching partition of the other partitioned table; no row from non-matching
>
> There could be more than one. I'd write: The equi-join between
> partition keys implies that all join partners for a given row in one
> partitioned table must be in the corresponding partition of the other
> partitioned table.
Done. I think it's important to emphasize the the joining partners can
not be in other partitions. So, added that sentence after your
suggested sentence.
>
> +#include "miscadmin.h"
> #include <limits.h>
> #include <math.h>
>
> Added in wrong place.
Done.
>
> + * System attributes do not need
> translation. In such a case,
> + * the attribute numbers of the parent
> and the child should
> + * start from the same minimum attribute.
>
> I would delete the second sentence and add an Assert() to that effect instead.
The assertion is there just few lines down. Please let me know if that
suffices. Deleted the second sentence.
>
> + /* Pass top parent's relids down the inheritance hierarchy. */
>
> Why?
That is required for a multi-level partitioned table.
top_parent_relids are used for translating expressions of the top
parent to that of child table.
>
> + for (attno = rel->min_attr; attno <=
> rel->max_attr; attno++)
>
> Add add a comment explaining why we need to do this.
The comment is there just few lines above. I have moved it just above
this for loop.
>
> - add_paths_to_append_rel(root, rel, live_childrels);
> + add_paths_to_append_rel(root, rel, live_childrels, false);
> }
>
> -
>
> No need to remove blank line.
Sorry. That was added by my patch to refactor
set_append_rel_pathlist(). I have added a patch in the series to
remove that line.
>
> + * When called on partitioned join relation with partition_join_path = true, it
> + * adds PartitionJoinPath instead of Merge/Append path. This path is costed
> + * based on the costs of sampled child-join and is expanded later into
> + * Merge/Append plan.
>
> I'm not a big fan of the Merge/Append terminology here. If somebody
> adds another kind of append-path someday, then all of these comments
> will have to be updated. I think this can be phrased more
> generically.
Reworded as
+ * When partition_join_path is true, the caller intends to add a
+ * PartitionJoinPath costed based on the sampled child-joins passed as
+ * live_childrels.
Also added an assertion to make sure the partition_join_path is true
only for join relations.
>
> /*
> + * While creating PartitionJoinPath, we sample paths from only
> a few child
> + * relations. Even if all of sampled children have partial
> paths, it's not
> + * guaranteed that all the unsampled children will have partial paths.
> + * Hence we do not create partial PartitionJoinPaths.
> + */
>
> Very sad. I guess if we had parallel append available, we could maybe
> dodge this problem, but for now I suppose we're stuck with it.
Really sad. Is there a way to look at the relation (without any
partial paths yet) and see whether the relation will have partial
paths or not. Even if we don't have actual partial paths but know that
there will be at least one added in the future, we will be able to fix
this problem.
>
> + /*
> + * Partitioning scheme in join relation indicates a possibility that the
> + * join may be partitioned, but it's not necessary that every pair of
> + * joining relations can use partition-wise join technique. If one of
> + * joining relations turns out to be unpartitioned, this pair of joining
> + * relations can not use partition-wise join technique.
> + */
> + if (!rel1->part_scheme || !rel2->part_scheme)
> + return;
>
> How can this happen? If rel->part_scheme != NULL, doesn't that imply
> that every rel covered by the joinrel is partitioned that way, and
> therefore this condition must necessarily hold?
I don't remember exactly, but this was added considering a more
generic partition-wise join. But then we would have more changes when
we support that. So, turned this into an assertion.
>
> In general, I think it's better style to write explicit tests against
> NULL or NIL than to just write if (blahptr).
PG code uses both the styles. Take for example
src/backend/rewrite/rewriteManip.c or any file, both styles are being
used. I find this style useful, when I want to code, say "if this
relation does not have a partitioning scheme" rather than "if this
relation have NULL partitioning scheme". Although I don't have
objections changing it as per your suggestion.
>
> + partitioned_join->sjinfo = copyObject(parent_sjinfo);
>
> Why do we need to copy it?
>
sjinfo in make_join_rel() may be from root->join_info_list or it could
be one made up locally in that function. The one made up in that
function would go away with that function, whereas we need it much
later to create paths for child-joins. So, I thought it's better to
copy it. But now I have changed to code to pass NULL for a made-up
sjinfo. In such a case, the child-join's sjinfo is also made up. This
required some refactoring to separate out the making-up code. So,
there's new refactoring patch.
> + /*
> + * Remove the relabel decoration. We can assume that there is
> at most one
> + * RelabelType node; eval_const_expressions() simplifies multiple
> + * RelabelType nodes into one.
> + */
> + if (IsA(expr, RelabelType))
> + expr = (Expr *) ((RelabelType *) expr)->arg;
>
> Still, instead of assuming this, you could just s/if/while/, and then
> you wouldn't need the assumption any more. Also, consider castNode().
Done.
>
> partition_wise_plan_weight may be useful for testing, but I don't
> think it should be present in the final patch.
partition_join test needs it so that it can work with smaller dataset
and complete faster. For smaller data sets the partition-wise join
paths come out to be costlier than other kinds and are never chosen.
By setting partition_wise_plan_weight I can force partition-wise join
to be chosen. An alternate solution would be to use
sample_partition_fraction = 1.0, but then we will never test delayed
planning for unsampled child-joins. I also think that users will find
partition_wise_plan_weight useful when estimates based on samples are
unrealistic. Obviously, in a longer run we should be able to provide
better estimates.
Apart from this, I have also removed recursive calls to
try_partition_wise_join() and generate_partition_wise_join_paths()
from 0009 and places them in the 0014 patch. Those are required for
multi-level partitioned tables, which are not supported in 0009.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Attachments:
[application/zip] pg_dp_join_patches_v4.zip (88.8K, ../../CAFjFpRfbndFZUqM8u64nCcz8fEsgyDXEpq9Ma3jGziyoBJ8Bkw@mail.gmail.com/2-pg_dp_join_patches_v4.zip)
download
^ permalink raw reply [nested|flat] 277+ messages in thread
* Re: Partition-wise join for join between (declaratively) partitioned tables
2017-03-01 08:56 Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-09 01:14 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-10 10:43 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-13 19:24 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-14 12:04 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 00:33 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-15 01:21 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-15 12:55 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
@ 2017-03-15 19:05 ` Robert Haas <[email protected]>
2017-03-16 01:40 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-16 10:51 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
0 siblings, 2 replies; 277+ messages in thread
From: Robert Haas @ 2017-03-15 19:05 UTC (permalink / raw)
To: Ashutosh Bapat <[email protected]>; +Cc: Rajkumar Raghuwanshi <[email protected]>; pgsql-hackers
On Wed, Mar 15, 2017 at 8:55 AM, Ashutosh Bapat
<[email protected]> wrote:
> Sorry. That was added by my patch to refactor
> set_append_rel_pathlist(). I have added a patch in the series to
> remove that line.
It's not worth an extra commit just to change what isn't broken.
Let's just leave it alone.
>> Very sad. I guess if we had parallel append available, we could maybe
>> dodge this problem, but for now I suppose we're stuck with it.
>
> Really sad. Is there a way to look at the relation (without any
> partial paths yet) and see whether the relation will have partial
> paths or not. Even if we don't have actual partial paths but know that
> there will be at least one added in the future, we will be able to fix
> this problem.
I don't think so. If we know that rel->consider_parallel will end up
true for a plain table, we should always get a parallel sequential
scan path at least, but if there are foreign tables involved, then
nothing is guaranteed.
>> partition_wise_plan_weight may be useful for testing, but I don't
>> think it should be present in the final patch.
>
> partition_join test needs it so that it can work with smaller dataset
> and complete faster. For smaller data sets the partition-wise join
> paths come out to be costlier than other kinds and are never chosen.
> By setting partition_wise_plan_weight I can force partition-wise join
> to be chosen. An alternate solution would be to use
> sample_partition_fraction = 1.0, but then we will never test delayed
> planning for unsampled child-joins. I also think that users will find
> partition_wise_plan_weight useful when estimates based on samples are
> unrealistic. Obviously, in a longer run we should be able to provide
> better estimates.
I still don't like it -- we have no other similar knob.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 277+ messages in thread
* Re: Partition-wise join for join between (declaratively) partitioned tables
2017-03-01 08:56 Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-09 01:14 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-10 10:43 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-13 19:24 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-14 12:04 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 00:33 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-15 01:21 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-15 12:55 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 19:05 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
@ 2017-03-16 01:40 ` Robert Haas <[email protected]>
2017-03-16 11:19 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
1 sibling, 1 reply; 277+ messages in thread
From: Robert Haas @ 2017-03-16 01:40 UTC (permalink / raw)
To: Ashutosh Bapat <[email protected]>; +Cc: Rajkumar Raghuwanshi <[email protected]>; pgsql-hackers
So I am looking at this part of 0008:
+ /*
+ * Do not copy parent_rinfo and child_rinfos because 1. they create a
+ * circular dependency between child and parent RestrictInfo 2. dropping
+ * those links just means that we loose some memory
optimizations. 3. There
+ * is a possibility that the child and parent RestrictInfots
themselves may
+ * have got copied and thus the old links may no longer be valid. The
+ * caller may set up those links itself, if needed.
+ */
I don't think that it's very clear whether or not this is safe. I
experimented with making _copyRestrictInfo PANIC, which,
interestingly, does not affect the core regression tests at all, but
does trip on this bit from the postgres_fdw tests:
-- subquery using stable function (can't be sent to remote)
PREPARE st2(int) AS SELECT * FROM ft1 t1 WHERE t1.c1 < $2 AND t1.c3 IN
(SELECT c3 FROM ft2 t2 WHERE c1 > $1 AND date(c4) =
'1970-01-17'::date) ORDER BY c1;
EXPLAIN (VERBOSE, COSTS OFF) EXECUTE st2(10, 20);
I'm not sure why this particular case is affected when so many others
are not, and the comment doesn't help me very much in figuring it out.
Why do we need this cache in the RestrictInfo, anyway? Aside from the
comment above, I looked at the comment in the RestrictInfo struct, and
I looked at the comment in build_child_restrictinfo, and I looked at
the comment in build_child_clauses, and I looked at the place where
build_child_clauses is called in set_append_rel_size, and none of
those places explain why we need this cache. I would assume we'd need
a separate translation of the RestrictInfo for every separate
child-join, so how does the cache help?
Maybe the answer is that build_child_clauses() is also called from
try_partition_wise_join() and add_paths_to_child_joinrel(), and those
three call sights all end up producing the same set of translated
RestrictInfos. But if that's the case, somehow it seems like we ought
to be producing these in one place where we can get convenient access
to them from each child join, rather than having to search through
this cache to find it. It's a pretty inefficient cache: it takes O(n)
time to search it, I think, where n is the number of partitions. And
you do O(n) searches. So it's an O(n^2) algorithm, which is a little
unfortunate. Can't we affix the translated RestrictInfos someplace
where they can be found more efficiently?
Yet another thing that the comments don't explain is why the existing
adjust_appendrel_attrs call needs to be replaced with
build_child_clauses.
So I feel, overall, that the point of all of this is not explained well at all.
...Robert
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 277+ messages in thread
* Re: Partition-wise join for join between (declaratively) partitioned tables
2017-03-01 08:56 Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-09 01:14 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-10 10:43 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-13 19:24 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-14 12:04 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 00:33 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-15 01:21 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-15 12:55 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 19:05 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-16 01:40 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
@ 2017-03-16 11:19 ` Ashutosh Bapat <[email protected]>
2017-03-16 15:06 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
0 siblings, 1 reply; 277+ messages in thread
From: Ashutosh Bapat @ 2017-03-16 11:19 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: Rajkumar Raghuwanshi <[email protected]>; pgsql-hackers
On Thu, Mar 16, 2017 at 7:10 AM, Robert Haas <[email protected]> wrote:
> So I am looking at this part of 0008:
>
> + /*
> + * Do not copy parent_rinfo and child_rinfos because 1. they create a
> + * circular dependency between child and parent RestrictInfo 2. dropping
> + * those links just means that we loose some memory
> optimizations. 3. There
> + * is a possibility that the child and parent RestrictInfots
> themselves may
> + * have got copied and thus the old links may no longer be valid. The
> + * caller may set up those links itself, if needed.
> + */
>
> I don't think that it's very clear whether or not this is safe. I
> experimented with making _copyRestrictInfo PANIC,
I am not able to understand how to make _copyRestrictInfo PANIC. Can
you please share the patch or compiler flags or settings? I will look
at the case below once I have that.
> which,
> interestingly, does not affect the core regression tests at all, but
> does trip on this bit from the postgres_fdw tests:
>
> -- subquery using stable function (can't be sent to remote)
> PREPARE st2(int) AS SELECT * FROM ft1 t1 WHERE t1.c1 < $2 AND t1.c3 IN
> (SELECT c3 FROM ft2 t2 WHERE c1 > $1 AND date(c4) =
> '1970-01-17'::date) ORDER BY c1;
> EXPLAIN (VERBOSE, COSTS OFF) EXECUTE st2(10, 20);
>
> I'm not sure why this particular case is affected when so many others
> are not, and the comment doesn't help me very much in figuring it out.
>
> Why do we need this cache in the RestrictInfo, anyway? Aside from the
> comment above, I looked at the comment in the RestrictInfo struct, and
> I looked at the comment in build_child_restrictinfo, and I looked at
> the comment in build_child_clauses, and I looked at the place where
> build_child_clauses is called in set_append_rel_size, and none of
> those places explain why we need this cache. I would assume we'd need
> a separate translation of the RestrictInfo for every separate
> child-join, so how does the cache help?
>
> Maybe the answer is that build_child_clauses() is also called from
> try_partition_wise_join() and add_paths_to_child_joinrel(), and those
> three call sights all end up producing the same set of translated
> RestrictInfos. But if that's the case, somehow it seems like we ought
> to be producing these in one place where we can get convenient access
> to them from each child join, rather than having to search through
> this cache to find it.
I had explained this briefly in [1]. But forgot to add it as comments.
There are multiple means by which a RestrictInfo gets translated
multiple times for the same child.
1. Consider a join A J (B J C on B.b = C.c) ON (A.a = B.b) the clause
A.a = B.b is part of the restrictlist for orders (AB)C and A(BC) (and
(AC)B depending upon the type of join). So, the clause gets translated
twice once for each of those join orders.
2. In the above example, A.a = B.b is part of joininfo list (if it
happens to be an outer join) of A, B and BC. So, it should be part of
joininfo list of children of A, B and BC. But the RestrictInfo which
is part of joininfo of B and BC looks exactly same.
Similarly param_info->clauses get translated multiple times each time
with a different set of required_outer.
In order to avoid multiple translations and spend memory in each
translation it's better to cache the result and retrieve it.
Updated prologue of build_child_restrictinfo with this explanation.
> It's a pretty inefficient cache: it takes O(n)
> time to search it, I think, where n is the number of partitions.
Above explanation shows that it's worse than that.
> And
> you do O(n) searches. So it's an O(n^2) algorithm, which is a little
> unfortunate. Can't we affix the translated RestrictInfos someplace
> where they can be found more efficiently?
Would a hash similar to root->join_rel_hash help? That will reduce the
searches to O(1). I have added a separate patch (0008) for using
hashtable to store child restrictinfos. If that patch looks good to
you, I will merge it with the main patch supporting partition-wise
join.
>
> Yet another thing that the comments don't explain is why the existing
> adjust_appendrel_attrs call needs to be replaced with
> build_child_clauses.
The call to adjust_appendrel_attrs() used to translate joininfo for
child has been replaced by build_child_clauses to take advantage of
the RestrictInfo cache. As explained above a clause which is part of
joininfo of a child, is also part of joininfo of the child-join in
which it participates except the child-joins covering the clause. So,
a cached copy of that RestrictInfo helps. I have added a patch (0010)
to use build_child_clause() only for partitioned tables and use
adjust_appendrel_attrs() for non-partitioned case. If this change
looks good, I will merge it with the main patch.
>
> So I feel, overall, that the point of all of this is not explained well at all.
Sorry for that. I should have added the explanation in the comments.
Corrected this in this set of patches.
[1] https://www.postgresql.org/message-id/CAFjFpRe66z%2Bw9%2BdnAkWGiaB1CU2CUQsLGsqzHzYBoA%3DKJFf%2BPQ%40...
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Attachments:
[application/zip] pg_dp_join_patches_v5.zip (91.6K, ../../CAFjFpRcCH0Xm+Ae6jArpN2ychoX4NWseMji6o81uUM7Sbv6+_A@mail.gmail.com/2-pg_dp_join_patches_v5.zip)
download
^ permalink raw reply [nested|flat] 277+ messages in thread
* Re: Partition-wise join for join between (declaratively) partitioned tables
2017-03-01 08:56 Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-09 01:14 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-10 10:43 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-13 19:24 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-14 12:04 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 00:33 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-15 01:21 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-15 12:55 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 19:05 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-16 01:40 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-16 11:19 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
@ 2017-03-16 15:06 ` Robert Haas <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Robert Haas @ 2017-03-16 15:06 UTC (permalink / raw)
To: Ashutosh Bapat <[email protected]>; +Cc: Rajkumar Raghuwanshi <[email protected]>; pgsql-hackers
On Thu, Mar 16, 2017 at 7:19 AM, Ashutosh Bapat
<[email protected]> wrote:
> On Thu, Mar 16, 2017 at 7:10 AM, Robert Haas <[email protected]> wrote:
>> So I am looking at this part of 0008:
>>
>> + /*
>> + * Do not copy parent_rinfo and child_rinfos because 1. they create a
>> + * circular dependency between child and parent RestrictInfo 2. dropping
>> + * those links just means that we loose some memory
>> optimizations. 3. There
>> + * is a possibility that the child and parent RestrictInfots
>> themselves may
>> + * have got copied and thus the old links may no longer be valid. The
>> + * caller may set up those links itself, if needed.
>> + */
>>
>> I don't think that it's very clear whether or not this is safe. I
>> experimented with making _copyRestrictInfo PANIC,
>
> I am not able to understand how to make _copyRestrictInfo PANIC. Can
> you please share the patch or compiler flags or settings? I will look
> at the case below once I have that.
I just put elog(PANIC, "_copyRestrictInfo") into the function.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 277+ messages in thread
* Re: Partition-wise join for join between (declaratively) partitioned tables
2017-03-01 08:56 Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-09 01:14 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-10 10:43 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-13 19:24 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-14 12:04 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 00:33 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-15 01:21 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-15 12:55 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 19:05 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
@ 2017-03-16 10:51 ` Ashutosh Bapat <[email protected]>
1 sibling, 0 replies; 277+ messages in thread
From: Ashutosh Bapat @ 2017-03-16 10:51 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: Rajkumar Raghuwanshi <[email protected]>; pgsql-hackers
On Thu, Mar 16, 2017 at 12:35 AM, Robert Haas <[email protected]> wrote:
> On Wed, Mar 15, 2017 at 8:55 AM, Ashutosh Bapat
> <[email protected]> wrote:
>> Sorry. That was added by my patch to refactor
>> set_append_rel_pathlist(). I have added a patch in the series to
>> remove that line.
>
> It's not worth an extra commit just to change what isn't broken.
> Let's just leave it alone.
Ok. Removed that patch from the set of patches.
>
>>> Very sad. I guess if we had parallel append available, we could maybe
>>> dodge this problem, but for now I suppose we're stuck with it.
>>
>> Really sad. Is there a way to look at the relation (without any
>> partial paths yet) and see whether the relation will have partial
>> paths or not. Even if we don't have actual partial paths but know that
>> there will be at least one added in the future, we will be able to fix
>> this problem.
>
> I don't think so. If we know that rel->consider_parallel will end up
> true for a plain table, we should always get a parallel sequential
> scan path at least, but if there are foreign tables involved, then
> nothing is guaranteed.
Ok.
>
>>> partition_wise_plan_weight may be useful for testing, but I don't
>>> think it should be present in the final patch.
>>
>> partition_join test needs it so that it can work with smaller dataset
>> and complete faster. For smaller data sets the partition-wise join
>> paths come out to be costlier than other kinds and are never chosen.
>> By setting partition_wise_plan_weight I can force partition-wise join
>> to be chosen. An alternate solution would be to use
>> sample_partition_fraction = 1.0, but then we will never test delayed
>> planning for unsampled child-joins. I also think that users will find
>> partition_wise_plan_weight useful when estimates based on samples are
>> unrealistic. Obviously, in a longer run we should be able to provide
>> better estimates.
>
> I still don't like it -- we have no other similar knob.
We have another cost-skewing GUC, disable_cost, which adds a huge cost
to anything that needs to be disabled. This is different in the sense
that it multiplies the cost.
Well, in that case, we can replace it with force_partition_wise_plan
(on/off) for the sake of regression, to test with smaller data. Even
then we will need to adjust the costs, so that partition-wise join
plan comes out to be the cheapest. Probably we will need set
partition-wise join plan costs to very low or even 0 when
force_partition_wise_plan is set to on. Does that look good? Any other
ideas?
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 277+ messages in thread
* Re: Partition-wise join for join between (declaratively) partitioned tables
2017-03-01 08:56 Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-09 01:14 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-10 10:43 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-13 19:24 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-14 12:04 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 00:33 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
@ 2017-03-15 12:49 ` Ashutosh Bapat <[email protected]>
2017-03-15 19:00 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
1 sibling, 1 reply; 277+ messages in thread
From: Ashutosh Bapat @ 2017-03-15 12:49 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: Rajkumar Raghuwanshi <[email protected]>; pgsql-hackers
>>
>> There are some differences in what geqo does and what partition-wise
>> needs to do. geqo tries many joining orders each one in a separate
>> temporary context. The way geqo slices the work, every slice produces
>> a full plan. For partition-wise join I do not see a way to slice the
>> work such that the whole path and corresponding RelOptInfos come from
>> the same slice. So, we can't use the same method as GEQO.
>
> What I was thinking about was the use of this technique for getting
> rid of joinrels:
>
> root->join_rel_list = list_truncate(root->join_rel_list,
> savelength);
> root->join_rel_hash = savehash;
>
> makePathNode() serves to segregate paths into a separate memory
> context that can then be destroyed, but as you point out, the path
> lists are still hanging around, and so are the RelOptInfo nodes. It
> seems to me we could do a lot better using this technique. Suppose we
> jigger things so that the List objects created by add_path go into
> path_cxt, and so that RelOptInfo nodes also go into path_cxt. Then
> when we blow up path_cxt we won't have dangling pointers in the
> RelOptInfo objects any more because the RelOptInfos themselves will be
> gone. The only problem is that the join_rel_list (and join_rel_hash
> if it exists) will be corrupt, but we can fix that using the technique
> demonstrated above.
>
> Of course, that supposes that 0009 can manage to postpone creating
> non-sampled child joinrels until create_partition_join_plan(), which
> it currently doesn't.
Right. We need the child-join's RelOptInfos to estimate sizes, so that
we could sample the largest ones. So postponing it looks difficult.
> In fact, unless I'm missing something, 0009
> hasn't been even slightly adapted to take advantage of the
> infrastructure in 0001; it doesn't seem to reset the path_cxt or
> anything. That seems like a fairly major omission.
The path_cxt reset introduced by 0001 recycles memory used by all the
paths, including paths created for the children. But that happens only
after all the planning has completed. I thought that's what we
discussed to be done. We could create a separate path context for
every top-level child-join. That will require either copying the
cheapest path-tree into root->glob->path_cxt memory context OR will
require it to be converted to a plan immediately. The first will
require spending CPU cycles and memory in copying path-tree. The later
requires almost all the create_*_append_plan() code to be duplicated
in create_partition_join_plan() which is ugly. In an earlier version
of this patch I had that code, which I got rid of in the latest set of
patches. Between those two the first looks better.
>
> Incidentally, I committed 0002, 0003, and 0005 as a single commit with
> a few tweaks; I think you may need to do a bit of rebasing.
Thanks. I will have fewer patches to rebase now :).
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 277+ messages in thread
* Re: Partition-wise join for join between (declaratively) partitioned tables
2017-03-01 08:56 Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-09 01:14 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-10 10:43 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-13 19:24 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-14 12:04 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 00:33 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-15 12:49 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
@ 2017-03-15 19:00 ` Robert Haas <[email protected]>
2017-03-16 10:48 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
0 siblings, 1 reply; 277+ messages in thread
From: Robert Haas @ 2017-03-15 19:00 UTC (permalink / raw)
To: Ashutosh Bapat <[email protected]>; +Cc: Rajkumar Raghuwanshi <[email protected]>; pgsql-hackers
On Wed, Mar 15, 2017 at 8:49 AM, Ashutosh Bapat
<[email protected]> wrote:
>> Of course, that supposes that 0009 can manage to postpone creating
>> non-sampled child joinrels until create_partition_join_plan(), which
>> it currently doesn't.
>
> Right. We need the child-join's RelOptInfos to estimate sizes, so that
> we could sample the largest ones. So postponing it looks difficult.
You have a point.
>> In fact, unless I'm missing something, 0009
>> hasn't been even slightly adapted to take advantage of the
>> infrastructure in 0001; it doesn't seem to reset the path_cxt or
>> anything. That seems like a fairly major omission.
>
> The path_cxt reset introduced by 0001 recycles memory used by all the
> paths, including paths created for the children. But that happens only
> after all the planning has completed. I thought that's what we
> discussed to be done. We could create a separate path context for
> every top-level child-join.
I don't think we need to create a new context for each top-level
child-join, but I think we should create a context to be used across
all top-level child-joins and then reset it after planning each one.
I thought the whole point here was that NOT doing that caused the
memory usage for partitionwise join to get out of control. Am I
confused?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 277+ messages in thread
* Re: Partition-wise join for join between (declaratively) partitioned tables
2017-03-01 08:56 Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-09 01:14 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-10 10:43 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-13 19:24 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-14 12:04 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 00:33 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-15 12:49 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 19:00 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
@ 2017-03-16 10:48 ` Ashutosh Bapat <[email protected]>
2017-03-16 15:05 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
0 siblings, 1 reply; 277+ messages in thread
From: Ashutosh Bapat @ 2017-03-16 10:48 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: Rajkumar Raghuwanshi <[email protected]>; pgsql-hackers
On Thu, Mar 16, 2017 at 12:30 AM, Robert Haas <[email protected]> wrote:
> On Wed, Mar 15, 2017 at 8:49 AM, Ashutosh Bapat
> <[email protected]> wrote:
>>> Of course, that supposes that 0009 can manage to postpone creating
>>> non-sampled child joinrels until create_partition_join_plan(), which
>>> it currently doesn't.
>>
>> Right. We need the child-join's RelOptInfos to estimate sizes, so that
>> we could sample the largest ones. So postponing it looks difficult.
>
> You have a point.
>
>>> In fact, unless I'm missing something, 0009
>>> hasn't been even slightly adapted to take advantage of the
>>> infrastructure in 0001; it doesn't seem to reset the path_cxt or
>>> anything. That seems like a fairly major omission.
>>
>> The path_cxt reset introduced by 0001 recycles memory used by all the
>> paths, including paths created for the children. But that happens only
>> after all the planning has completed. I thought that's what we
>> discussed to be done. We could create a separate path context for
>> every top-level child-join.
>
> I don't think we need to create a new context for each top-level
> child-join, but I think we should create a context to be used across
> all top-level child-joins and then reset it after planning each one.
Sorry, that's what I meant by creating a new context for each
top-level child-join. So, we need to copy the required path tree
before resetting the context. I am fine doing that but read on.
> I thought the whole point here was that NOT doing that caused the
> memory usage for partitionwise join to get out of control. Am I
> confused?
We took a few steps to reduce the memory footprint of partition-wise
join in [1] and [2]. According to the numbers reported in [1] and then
in [2], if the total memory consumed by a planner is 44MB (memory
consumed by paths 150K) for a 5-way non-parition-wise join between
tables with 1000 partitions, partition-wise join consumed 192MB which
is 4.4 times the non-partitino-wise case. The earlier implementation
of blowing away a memory context after each top-level child-join, just
got rid of the paths created for that child-join. The total memory
consumed by paths created for all the child-joins was about 150MB.
Remember that we can not get rid of memory consumed by expressions,
RelOptInfos, RestrictInfos etc. since their pointers will be copied
into the plan nodes.
With changes in 0001, what happens is we accumulate 150MB till the end
of the planning and get rid of it after we have created a plan. So,
till the plan is created we are consuming approx. 192MB + 150MB =
342MB memory and are getting rid of 150MB memory after we have created
the plan. I am not sure whether consuming extra 150MB or for that
matter 342MB in a setup with a thousand partitions is "going out of
control". (342MB is approx. 7.8 time 44MB; not 1000 times, and not
even 10 times). But if you think that we should throw away unused
paths after planning every top-level child-join I am fine with it.
[1] https://www.postgresql.org/message-id/CAFjFpRcZ_M3-JxoiDkdoPS%2B-9Cok4ux9Si%2B4drcRL-62af%3DjWw@mail...
[2] https://www.postgresql.org/message-id/CAFjFpRe66z%2Bw9%2BdnAkWGiaB1CU2CUQsLGsqzHzYBoA%3DKJFf%2BPQ%40...
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 277+ messages in thread
* Re: Partition-wise join for join between (declaratively) partitioned tables
2017-03-01 08:56 Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-09 01:14 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-10 10:43 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-13 19:24 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-14 12:04 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 00:33 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-15 12:49 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 19:00 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-16 10:48 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
@ 2017-03-16 15:05 ` Robert Haas <[email protected]>
2017-03-17 10:28 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
0 siblings, 1 reply; 277+ messages in thread
From: Robert Haas @ 2017-03-16 15:05 UTC (permalink / raw)
To: Ashutosh Bapat <[email protected]>; +Cc: Rajkumar Raghuwanshi <[email protected]>; pgsql-hackers
On Thu, Mar 16, 2017 at 6:48 AM, Ashutosh Bapat
<[email protected]> wrote:
>> I thought the whole point here was that NOT doing that caused the
>> memory usage for partitionwise join to get out of control. Am I
>> confused?
>
> We took a few steps to reduce the memory footprint of partition-wise
> join in [1] and [2]. According to the numbers reported in [1] and then
> in [2], if the total memory consumed by a planner is 44MB (memory
> consumed by paths 150K) for a 5-way non-parition-wise join between
> tables with 1000 partitions, partition-wise join consumed 192MB which
> is 4.4 times the non-partitino-wise case. The earlier implementation
> of blowing away a memory context after each top-level child-join, just
> got rid of the paths created for that child-join. The total memory
> consumed by paths created for all the child-joins was about 150MB.
> Remember that we can not get rid of memory consumed by expressions,
> RelOptInfos, RestrictInfos etc. since their pointers will be copied
> into the plan nodes.
All right, I propose that we revise our plan for attacking this
problem. The code in this patch that proposes to reduce memory
utilization is very complicated and it's likely to cause us to miss
this release altogether if we keep hacking on it. So, I propose that
you refactor this patch series so that the first big patch is
partition-wise join without any of the optimizations that save memory
- essentially the sample_partition_fraction = 1 case with all
memory-saving optimizations removed. If it's only there to save
memory, rip it out. Also, change the default value of
enable_partition_wise_join to false and document that turning it on
may cause a large increase in planner memory utilization, and that's
why it's not enabled by default.
If we get that committed, then we can have follow-on patches that add
the incremental path creation stuff and other memory-saving features,
and then at the end we can flip the default from "off" to "on".
Probably that last part will slip beyond v10 since we're only two
weeks from the end of the release cycle, but I think that's still
better than having everything slip. Let's also put the multi-level
partition-wise join stuff ahead of the memory-saving stuff, because
being able to do only a single-level of partition-wise join is a
fairly unimpressive feature; I'm not sure this is really even
committable without that.
I realize in some sense that I'm telling you to go and undo all of the
work that you just did based on what I told you before, but I think
we've actually made some pretty good progress here: it's now clear
that there are viable strategies for getting the memory usage down to
an acceptable level, and we've got draft patches for those strategies.
So committing the core feature without immediately including that work
can't be regarded as breaking everything hopelessly; rather, it now
looks (I think, anyway) like a reasonable intermediate step towards
the eventual goal.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 277+ messages in thread
* Re: Partition-wise join for join between (declaratively) partitioned tables
2017-03-01 08:56 Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-09 01:14 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-10 10:43 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-13 19:24 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-14 12:04 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 00:33 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-15 12:49 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 19:00 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-16 10:48 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-16 15:05 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
@ 2017-03-17 10:28 ` Ashutosh Bapat <[email protected]>
2017-03-17 13:15 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
0 siblings, 1 reply; 277+ messages in thread
From: Ashutosh Bapat @ 2017-03-17 10:28 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: Rajkumar Raghuwanshi <[email protected]>; pgsql-hackers
On Thu, Mar 16, 2017 at 8:35 PM, Robert Haas <[email protected]> wrote:
> On Thu, Mar 16, 2017 at 6:48 AM, Ashutosh Bapat
> <[email protected]> wrote:
>>> I thought the whole point here was that NOT doing that caused the
>>> memory usage for partitionwise join to get out of control. Am I
>>> confused?
>>
>> We took a few steps to reduce the memory footprint of partition-wise
>> join in [1] and [2]. According to the numbers reported in [1] and then
>> in [2], if the total memory consumed by a planner is 44MB (memory
>> consumed by paths 150K) for a 5-way non-parition-wise join between
>> tables with 1000 partitions, partition-wise join consumed 192MB which
>> is 4.4 times the non-partitino-wise case. The earlier implementation
>> of blowing away a memory context after each top-level child-join, just
>> got rid of the paths created for that child-join. The total memory
>> consumed by paths created for all the child-joins was about 150MB.
>> Remember that we can not get rid of memory consumed by expressions,
>> RelOptInfos, RestrictInfos etc. since their pointers will be copied
>> into the plan nodes.
>
> All right, I propose that we revise our plan for attacking this
> problem. The code in this patch that proposes to reduce memory
> utilization is very complicated and it's likely to cause us to miss
> this release altogether if we keep hacking on it. So, I propose that
> you refactor this patch series so that the first big patch is
> partition-wise join without any of the optimizations that save memory
> - essentially the sample_partition_fraction = 1 case with all
> memory-saving optimizations removed. If it's only there to save
> memory, rip it out. Also, change the default value of
> enable_partition_wise_join to false and document that turning it on
> may cause a large increase in planner memory utilization, and that's
> why it's not enabled by default.
>
> If we get that committed, then we can have follow-on patches that add
> the incremental path creation stuff and other memory-saving features,
> and then at the end we can flip the default from "off" to "on".
> Probably that last part will slip beyond v10 since we're only two
> weeks from the end of the release cycle, but I think that's still
> better than having everything slip. Let's also put the multi-level
> partition-wise join stuff ahead of the memory-saving stuff, because
> being able to do only a single-level of partition-wise join is a
> fairly unimpressive feature; I'm not sure this is really even
> committable without that.
>
> I realize in some sense that I'm telling you to go and undo all of the
> work that you just did based on what I told you before, but I think
> we've actually made some pretty good progress here: it's now clear
> that there are viable strategies for getting the memory usage down to
> an acceptable level, and we've got draft patches for those strategies.
> So committing the core feature without immediately including that work
> can't be regarded as breaking everything hopelessly; rather, it now
> looks (I think, anyway) like a reasonable intermediate step towards
> the eventual goal.
Here's the set of patches with all the memory saving stuff removed.
It's now bare partition-wise joins. I have tried to eliminate all
memory saving stuff carefully, except few bms_free() and list_free()
which fit the functions they were part of and mostly were present in
my earlier versions of patches. But I might have missed some. Also, I
have corrected any indentation/white space mistakes introduced by
editing patches with +/-, but I might have missed some. Please let me
know.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Attachments:
[application/zip] pg_dp_join_patches_v6.zip (65.7K, ../../CAFjFpRfSvEA1n_8w102hjyNOnr4P8OGUX6TDEfR-o12g=uJD0Q@mail.gmail.com/2-pg_dp_join_patches_v6.zip)
download
^ permalink raw reply [nested|flat] 277+ messages in thread
* Re: Partition-wise join for join between (declaratively) partitioned tables
2017-03-01 08:56 Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-09 01:14 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-10 10:43 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-13 19:24 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-14 12:04 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 00:33 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-15 12:49 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 19:00 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-16 10:48 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-16 15:05 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-17 10:28 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
@ 2017-03-17 13:15 ` Ashutosh Bapat <[email protected]>
2017-03-18 00:10 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
0 siblings, 1 reply; 277+ messages in thread
From: Ashutosh Bapat @ 2017-03-17 13:15 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: Rajkumar Raghuwanshi <[email protected]>; pgsql-hackers
>
> Here's the set of patches with all the memory saving stuff removed.
> It's now bare partition-wise joins. I have tried to eliminate all
> memory saving stuff carefully, except few bms_free() and list_free()
> which fit the functions they were part of and mostly were present in
> my earlier versions of patches. But I might have missed some. Also, I
> have corrected any indentation/white space mistakes introduced by
> editing patches with +/-, but I might have missed some. Please let me
> know.
>
Rajkumar offlist reported two issues with earlier set of patches.
1. 0008 conflicted with latest changes in postgres_fdw/deparse.c.
2. In the earlier set of patches part_scheme of a join relation was
being set when joining relations had same part_scheme even if there
was no equi-join between partition keys. The idea being that
rel->part_scheme and rel->part_rels together tell whether a relation
is partitioned or not. At a later stage if none of the joining pairs
resulted in partitioned join, part_rels would be NULL and then we
would reset part_scheme as well. But this logic not required. For the
exact partition scheme matching, that we are using, if one pair of
joining relation has an equi-join on partition keys, and both of those
have exactly same partitioning scheme, all other pairs of joining
relations would have an equi-join on partition keys and also exactly
same partitioning scheme. So, we can set part_scheme only by looking
at the first pair of joining relation while building the child-join.
This set of patches fixes both of those things.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Attachments:
[application/zip] pg_dp_join_patches_v7.zip (65.7K, ../../CAFjFpRfKstjH_aoXkyUx0m-R8HudFv2=1NrLyFY=V4xxP3yP8w@mail.gmail.com/2-pg_dp_join_patches_v7.zip)
download
^ permalink raw reply [nested|flat] 277+ messages in thread
* Re: Partition-wise join for join between (declaratively) partitioned tables
2017-03-01 08:56 Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-09 01:14 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-10 10:43 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-13 19:24 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-14 12:04 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 00:33 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-15 12:49 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 19:00 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-16 10:48 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-16 15:05 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-17 10:28 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-17 13:15 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
@ 2017-03-18 00:10 ` Robert Haas <[email protected]>
2017-03-19 04:15 ` Re: Partition-wise join for join between (declaratively) partitioned tables Rafia Sabih <[email protected]>
2017-03-20 02:51 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 13:44 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
0 siblings, 3 replies; 277+ messages in thread
From: Robert Haas @ 2017-03-18 00:10 UTC (permalink / raw)
To: Ashutosh Bapat <[email protected]>; +Cc: Rajkumar Raghuwanshi <[email protected]>; pgsql-hackers
On Fri, Mar 17, 2017 at 9:15 AM, Ashutosh Bapat
<[email protected]> wrote:
> This set of patches fixes both of those things.
0001 changes the purpose of a function and then 0007 renames it. It
would be better to include the renaming in 0001 so that you're not
taking multiple whacks at the same function in the same patch series.
I believe it would also be best to include 0011's changes to
adjust_appendrel_attrs_multilevel in 0001.
0002 should either add find_param_path_info() to the relevant header
file as extern from the beginning, or it should declare and define it
as static and then 0007 can remove those markings. It makes no sense
to declare it as extern but put the prototype in the .c file.
0004 still needs to be pared down. If you want to get something
committed this release cycle, you have to get these details taken care
of, uh, more or less immediately. Actually, preferably, several weeks
ago. You're welcome to maintain your own test suite locally but what
you submit should be what you are proposing for commit -- or if not,
then you should separate the part proposed for commit and the part
included for dev testing into two different patches.
In 0005's README, the part about planning partition-wise joins in two
phases needs to be removed. This patch also contains a small change
to partition_join.sql that belongs in 0004.
0008 removes direct tests against RELOPT_JOINREL almost everywhere,
but it overlooks the new ones added to postgres_fdw.c by
b30fb56b07a885f3476fe05920249f4832ca8da5. It should be updated to
cover those as well, I suspect. The commit message claims that it
will "Similarly replace RELOPT_OTHER_MEMBER_REL test with
IS_OTHER_REL() where we want to test for child relations of all kinds,
but in fact it makes exactly zero such substitutions.
While I was studying what you did with reparameterize_path_by_child(),
I started to wonder whether reparameterize_path() doesn't need to
start handling join paths. I think it only handles scan paths right
now because that's the only thing that can appear under an appendrel
created by inheritance expansion, but you're changing that. Maybe
it's not critical -- I think the worst consequences of missing some
handling there is that we won't consider a parameterized path in some
case where it would be advantageous to do so. Still, you might want
to investigate a bit.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 277+ messages in thread
* Re: Partition-wise join for join between (declaratively) partitioned tables
2017-03-01 08:56 Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-09 01:14 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-10 10:43 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-13 19:24 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-14 12:04 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 00:33 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-15 12:49 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 19:00 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-16 10:48 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-16 15:05 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-17 10:28 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-17 13:15 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-18 00:10 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
@ 2017-03-19 04:15 ` Rafia Sabih <[email protected]>
2017-03-20 02:39 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2 siblings, 1 reply; 277+ messages in thread
From: Rafia Sabih @ 2017-03-19 04:15 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: Ashutosh Bapat <[email protected]>; Rajkumar Raghuwanshi <[email protected]>; pgsql-hackers
On Sat, Mar 18, 2017 at 5:40 AM, Robert Haas <[email protected]> wrote:
> On Fri, Mar 17, 2017 at 9:15 AM, Ashutosh Bapat
> <[email protected]> wrote:
>> This set of patches fixes both of those things.
>
> 0001 changes the purpose of a function and then 0007 renames it. It
> would be better to include the renaming in 0001 so that you're not
> taking multiple whacks at the same function in the same patch series.
> I believe it would also be best to include 0011's changes to
> adjust_appendrel_attrs_multilevel in 0001.
>
> 0002 should either add find_param_path_info() to the relevant header
> file as extern from the beginning, or it should declare and define it
> as static and then 0007 can remove those markings. It makes no sense
> to declare it as extern but put the prototype in the .c file.
>
> 0004 still needs to be pared down. If you want to get something
> committed this release cycle, you have to get these details taken care
> of, uh, more or less immediately. Actually, preferably, several weeks
> ago. You're welcome to maintain your own test suite locally but what
> you submit should be what you are proposing for commit -- or if not,
> then you should separate the part proposed for commit and the part
> included for dev testing into two different patches.
>
> In 0005's README, the part about planning partition-wise joins in two
> phases needs to be removed. This patch also contains a small change
> to partition_join.sql that belongs in 0004.
>
> 0008 removes direct tests against RELOPT_JOINREL almost everywhere,
> but it overlooks the new ones added to postgres_fdw.c by
> b30fb56b07a885f3476fe05920249f4832ca8da5. It should be updated to
> cover those as well, I suspect. The commit message claims that it
> will "Similarly replace RELOPT_OTHER_MEMBER_REL test with
> IS_OTHER_REL() where we want to test for child relations of all kinds,
> but in fact it makes exactly zero such substitutions.
>
> While I was studying what you did with reparameterize_path_by_child(),
> I started to wonder whether reparameterize_path() doesn't need to
> start handling join paths. I think it only handles scan paths right
> now because that's the only thing that can appear under an appendrel
> created by inheritance expansion, but you're changing that. Maybe
> it's not critical -- I think the worst consequences of missing some
> handling there is that we won't consider a parameterized path in some
> case where it would be advantageous to do so. Still, you might want
> to investigate a bit.
>
I was trying to play around with this patch and came across following
case when without the patch query completes in 9 secs and with it in
15 secs. Theoretically, I tried to capture the case when each
partition is having good amount of rows in output and each has to
build their own hash, in that case the cost of building so many hashes
comes to be more costly than having an append and then join. Thought
it might be helpful to consider this case in better designing of the
algorithm. Please feel free to point out if I missed something.
Test details:
commit: b4ff8609dbad541d287b332846442b076a25a6df
Please find the attached .sql file for the complete schema and data
and .out file for the result of explain analyse with and without
patch.
--
Regards,
Rafia Sabih
EnterpriseDB: http://www.enterprisedb.com/
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Attachments:
[application/octet-stream] pwj_regress_test.out (25.7K, ../../CAOGQiiPw1miqWDBHjYWqr7BjofZRCvKpVti9VLUyoVEYN4x7DQ@mail.gmail.com/2-pwj_regress_test.out)
download
[application/octet-stream] test_case_pwj.sql (17.6K, ../../CAOGQiiPw1miqWDBHjYWqr7BjofZRCvKpVti9VLUyoVEYN4x7DQ@mail.gmail.com/3-test_case_pwj.sql)
download
^ permalink raw reply [nested|flat] 277+ messages in thread
* Re: Partition-wise join for join between (declaratively) partitioned tables
2017-03-01 08:56 Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-09 01:14 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-10 10:43 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-13 19:24 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-14 12:04 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 00:33 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-15 12:49 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 19:00 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-16 10:48 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-16 15:05 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-17 10:28 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-17 13:15 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-18 00:10 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-19 04:15 ` Re: Partition-wise join for join between (declaratively) partitioned tables Rafia Sabih <[email protected]>
@ 2017-03-20 02:39 ` Robert Haas <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Robert Haas @ 2017-03-20 02:39 UTC (permalink / raw)
To: Rafia Sabih <[email protected]>; +Cc: Ashutosh Bapat <[email protected]>; Rajkumar Raghuwanshi <[email protected]>; pgsql-hackers
On Sun, Mar 19, 2017 at 12:15 AM, Rafia Sabih
<[email protected]> wrote:
> I was trying to play around with this patch and came across following
> case when without the patch query completes in 9 secs and with it in
> 15 secs. Theoretically, I tried to capture the case when each
> partition is having good amount of rows in output and each has to
> build their own hash, in that case the cost of building so many hashes
> comes to be more costly than having an append and then join. Thought
> it might be helpful to consider this case in better designing of the
> algorithm. Please feel free to point out if I missed something.
In the non-partitionwise plan, the query planner correctly chooses to
hash the same table (prt2) and probe from the large table (prt). In
the partition-wise plan, it generally does the opposite. There is a
mix of merge joins and hash joins, but of the 15 children that picked
merge joins, 14 of them hashed the larger partition (in each case,
from prt) and probed from the smaller one (in each case, from prt2),
which seems like an odd strategy. So I think the problem is not that
building lots of hash tables is slower than building just one, but
rather that for some reason it's choosing the wrong table to hash.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 277+ messages in thread
* Re: Partition-wise join for join between (declaratively) partitioned tables
2017-03-01 08:56 Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-09 01:14 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-10 10:43 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-13 19:24 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-14 12:04 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 00:33 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-15 12:49 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 19:00 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-16 10:48 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-16 15:05 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-17 10:28 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-17 13:15 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-18 00:10 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
@ 2017-03-20 02:51 ` Robert Haas <[email protected]>
2017-03-20 13:44 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-20 16:07 ` Re: Partition-wise join for join between (declaratively) partitioned tables Rafia Sabih <[email protected]>
2 siblings, 2 replies; 277+ messages in thread
From: Robert Haas @ 2017-03-20 02:51 UTC (permalink / raw)
To: Ashutosh Bapat <[email protected]>; +Cc: Rajkumar Raghuwanshi <[email protected]>; pgsql-hackers
On Fri, Mar 17, 2017 at 8:10 PM, Robert Haas <[email protected]> wrote:
> While I was studying what you did with reparameterize_path_by_child(),
> I started to wonder whether reparameterize_path() doesn't need to
> start handling join paths. I think it only handles scan paths right
> now because that's the only thing that can appear under an appendrel
> created by inheritance expansion, but you're changing that. Maybe
> it's not critical -- I think the worst consequences of missing some
> handling there is that we won't consider a parameterized path in some
> case where it would be advantageous to do so. Still, you might want
> to investigate a bit.
I spent a fair amount of time this weekend musing over
reparameterize_path_by_child(). I think a key question for this patch
- as you already pointed out - is whether we're happy with that
approach. When we discover that we want to perform a partitionwise
parameterized nestloop, and therefore that we need the paths for each
inner appendrel to get their input values from the corresponding outer
appendrel members rather than from the outer parent, we've got two
choices. The first is to do what the patch actually does, which is to
build a new path tree for the nestloop inner path parameterized by the
appropriate childrel. The second is to use the existing paths, which
are parameterized by the parent rel, and then somehow allow make that
work. For example, you can imagine that create_plan_recurse() could
pass down a list of parameterized nestloops above the current point in
the path tree, and a parent-child mapping for each, and then we could
try to substitute everything while actually generating the plan
instead of creating paths sooner. Which is better?
It would be nice to hear opinions from anyone else who cares, but
after some thought I think the approach you've picked is probably
better, because it's more like what we do already. We have existing
precedent for reparameterizing a path, but none for allowing a Var for
one relation (the parent) to in effect refer to another relation (the
child).
That having been said, having try_nestloop_path() perform the
reparameterization at the very top of the function seems quite
undesirable. You're creating a new path there before you know whether
it's going to be rejected by the invalid-parameterization test and
also before you know whether initial_cost_nestloop is going to reject
it. It would be much better if you could find a way to postpone the
reparameterization until after those steps, and only do it if you're
going to try add_path().
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 277+ messages in thread
* Re: Partition-wise join for join between (declaratively) partitioned tables
2017-03-01 08:56 Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-09 01:14 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-10 10:43 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-13 19:24 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-14 12:04 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 00:33 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-15 12:49 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 19:00 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-16 10:48 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-16 15:05 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-17 10:28 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-17 13:15 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-18 00:10 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 02:51 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
@ 2017-03-20 13:44 ` Ashutosh Bapat <[email protected]>
2017-03-20 16:29 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
1 sibling, 1 reply; 277+ messages in thread
From: Ashutosh Bapat @ 2017-03-20 13:44 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: Rajkumar Raghuwanshi <[email protected]>; pgsql-hackers
On Mon, Mar 20, 2017 at 8:21 AM, Robert Haas <[email protected]> wrote:
> On Fri, Mar 17, 2017 at 8:10 PM, Robert Haas <[email protected]> wrote:
>> While I was studying what you did with reparameterize_path_by_child(),
>> I started to wonder whether reparameterize_path() doesn't need to
>> start handling join paths. I think it only handles scan paths right
>> now because that's the only thing that can appear under an appendrel
>> created by inheritance expansion, but you're changing that. Maybe
>> it's not critical -- I think the worst consequences of missing some
>> handling there is that we won't consider a parameterized path in some
>> case where it would be advantageous to do so. Still, you might want
>> to investigate a bit.
>
> I spent a fair amount of time this weekend musing over
> reparameterize_path_by_child(). I think a key question for this patch
> - as you already pointed out - is whether we're happy with that
> approach. When we discover that we want to perform a partitionwise
> parameterized nestloop, and therefore that we need the paths for each
> inner appendrel to get their input values from the corresponding outer
> appendrel members rather than from the outer parent, we've got two
> choices. The first is to do what the patch actually does, which is to
> build a new path tree for the nestloop inner path parameterized by the
> appropriate childrel. The second is to use the existing paths, which
> are parameterized by the parent rel, and then somehow allow make that
> work. For example, you can imagine that create_plan_recurse() could
> pass down a list of parameterized nestloops above the current point in
> the path tree, and a parent-child mapping for each, and then we could
> try to substitute everything while actually generating the plan
> instead of creating paths sooner. Which is better?
>
> It would be nice to hear opinions from anyone else who cares, but
> after some thought I think the approach you've picked is probably
> better, because it's more like what we do already. We have existing
> precedent for reparameterizing a path, but none for allowing a Var for
> one relation (the parent) to in effect refer to another relation (the
> child).
Right. If we could use parent Vars to indicate parent Var or child Var
depending upon the context, a lot of memory issues would be solved; we
wouldn't need to translate a single expression. But I think that's not
straight forward. I have been thinking about some kind of polymorphic
Var node, but it seems a lot more invasive change. Although, if we
could get something like that, we would save a huge memory. :)
>
> That having been said, having try_nestloop_path() perform the
> reparameterization at the very top of the function seems quite
> undesirable. You're creating a new path there before you know whether
> it's going to be rejected by the invalid-parameterization test and
> also before you know whether initial_cost_nestloop is going to reject
> it. It would be much better if you could find a way to postpone the
> reparameterization until after those steps, and only do it if you're
> going to try add_path().
Hmm. I think we can do that by refactoring
calc_nestloop_required_outer(), allow_star_schema_join() and
have_dangerous_phv() to use relids instead of paths. If the checks
pass for a join between parents, those should pass for joins between
children. Done in the attached set of patches.
try_nestloop_path has few new variables. Among those innerrelids and
outerrelids indicate the relids to be used by the parameterization
checks (see patch for details). They are not relids of inner and outer
relations resp. but kind of effective relids to be used. But I
couldn't come up with better names which convey proper meaning and
still are short enough. effective_innerrelids is mouthful.
I am wondering whether we need to change
calc_non_nestloop_required_outer() similar to
calc_nestloop_required_outer() just to keep their signatures in sync.
Should I work on completing reparamterized_path_by_child() to support
all kinds of paths?
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Attachments:
[application/zip] pg_dp_join_patches_v8.zip (56.3K, ../../CAFjFpRcbY2QN3cfeMTzVEoyF5Lfku-ijyNR=PbXj1e=9a=qMoQ@mail.gmail.com/2-pg_dp_join_patches_v8.zip)
download
^ permalink raw reply [nested|flat] 277+ messages in thread
* Re: Partition-wise join for join between (declaratively) partitioned tables
2017-03-01 08:56 Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-09 01:14 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-10 10:43 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-13 19:24 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-14 12:04 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 00:33 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-15 12:49 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 19:00 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-16 10:48 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-16 15:05 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-17 10:28 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-17 13:15 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-18 00:10 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 02:51 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 13:44 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
@ 2017-03-20 16:29 ` Robert Haas <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Robert Haas @ 2017-03-20 16:29 UTC (permalink / raw)
To: Ashutosh Bapat <[email protected]>; +Cc: Rajkumar Raghuwanshi <[email protected]>; pgsql-hackers
On Mon, Mar 20, 2017 at 9:44 AM, Ashutosh Bapat
<[email protected]> wrote:
> Right. If we could use parent Vars to indicate parent Var or child Var
> depending upon the context, a lot of memory issues would be solved; we
> wouldn't need to translate a single expression. But I think that's not
> straight forward. I have been thinking about some kind of polymorphic
> Var node, but it seems a lot more invasive change. Although, if we
> could get something like that, we would save a huge memory. :)
Yes, that's why I'm interested in exploring that approach once the
basic framework is in place here.
> I am wondering whether we need to change
> calc_non_nestloop_required_outer() similar to
> calc_nestloop_required_outer() just to keep their signatures in sync.
I haven't looked at the patch, but I don't think you need to worry about that.
> Should I work on completing reparamterized_path_by_child() to support
> all kinds of paths?
Yes, or at the very least all scans, like reparameterize_path() already does.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 277+ messages in thread
* Re: Partition-wise join for join between (declaratively) partitioned tables
2017-03-01 08:56 Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-09 01:14 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-10 10:43 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-13 19:24 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-14 12:04 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 00:33 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-15 12:49 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 19:00 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-16 10:48 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-16 15:05 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-17 10:28 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-17 13:15 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-18 00:10 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 02:51 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
@ 2017-03-20 16:07 ` Rafia Sabih <[email protected]>
2017-03-20 16:40 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 16:47 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
1 sibling, 2 replies; 277+ messages in thread
From: Rafia Sabih @ 2017-03-20 16:07 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: Ashutosh Bapat <[email protected]>; Rajkumar Raghuwanshi <[email protected]>; pgsql-hackers
On Mon, Mar 20, 2017 at 8:21 AM, Robert Haas <[email protected]> wrote:
> On Fri, Mar 17, 2017 at 8:10 PM, Robert Haas <[email protected]> wrote:
>> While I was studying what you did with reparameterize_path_by_child(),
>> I started to wonder whether reparameterize_path() doesn't need to
>> start handling join paths. I think it only handles scan paths right
>> now because that's the only thing that can appear under an appendrel
>> created by inheritance expansion, but you're changing that. Maybe
>> it's not critical -- I think the worst consequences of missing some
>> handling there is that we won't consider a parameterized path in some
>> case where it would be advantageous to do so. Still, you might want
>> to investigate a bit.
>
> I spent a fair amount of time this weekend musing over
> reparameterize_path_by_child(). I think a key question for this patch
> - as you already pointed out - is whether we're happy with that
> approach. When we discover that we want to perform a partitionwise
> parameterized nestloop, and therefore that we need the paths for each
> inner appendrel to get their input values from the corresponding outer
> appendrel members rather than from the outer parent, we've got two
> choices. The first is to do what the patch actually does, which is to
> build a new path tree for the nestloop inner path parameterized by the
> appropriate childrel. The second is to use the existing paths, which
> are parameterized by the parent rel, and then somehow allow make that
> work. For example, you can imagine that create_plan_recurse() could
> pass down a list of parameterized nestloops above the current point in
> the path tree, and a parent-child mapping for each, and then we could
> try to substitute everything while actually generating the plan
> instead of creating paths sooner. Which is better?
>
> It would be nice to hear opinions from anyone else who cares, but
> after some thought I think the approach you've picked is probably
> better, because it's more like what we do already. We have existing
> precedent for reparameterizing a path, but none for allowing a Var for
> one relation (the parent) to in effect refer to another relation (the
> child).
>
> That having been said, having try_nestloop_path() perform the
> reparameterization at the very top of the function seems quite
> undesirable. You're creating a new path there before you know whether
> it's going to be rejected by the invalid-parameterization test and
> also before you know whether initial_cost_nestloop is going to reject
> it. It would be much better if you could find a way to postpone the
> reparameterization until after those steps, and only do it if you're
> going to try add_path().
On a further testing of this patch I find another case when it is
showing regression, the time taken with patch is around 160 secs and
without it is 125 secs.
Another minor thing to note that is planning time is almost twice with
this patch, though I understand that this is for scenarios with really
big 'big data' so this may not be a serious issue in such cases, but
it'd be good if we can keep an eye on this that it doesn't exceed the
computational bounds for a really large number of tables..
Please find the attached .out file to check the output I witnessed and
let me know if anymore information is required
Schema and data was similar to the preciously shared schema with the
addition of more data for this case, parameter settings used were:
work_mem = 1GB
random_page_cost = seq_page_cost = 0.1
--
Regards,
Rafia Sabih
EnterpriseDB: http://www.enterprisedb.com/
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Attachments:
[application/octet-stream] pwj_regress_2.out (28.6K, ../../CAOGQiiMwcjNrunJ_fCDBscrTLeJ-CLp7exfzzipe2ut71n4LUA@mail.gmail.com/2-pwj_regress_2.out)
download
^ permalink raw reply [nested|flat] 277+ messages in thread
* Re: Partition-wise join for join between (declaratively) partitioned tables
2017-03-01 08:56 Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-09 01:14 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-10 10:43 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-13 19:24 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-14 12:04 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 00:33 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-15 12:49 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 19:00 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-16 10:48 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-16 15:05 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-17 10:28 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-17 13:15 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-18 00:10 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 02:51 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 16:07 ` Re: Partition-wise join for join between (declaratively) partitioned tables Rafia Sabih <[email protected]>
@ 2017-03-20 16:40 ` Robert Haas <[email protected]>
1 sibling, 0 replies; 277+ messages in thread
From: Robert Haas @ 2017-03-20 16:40 UTC (permalink / raw)
To: Rafia Sabih <[email protected]>; +Cc: Ashutosh Bapat <[email protected]>; Rajkumar Raghuwanshi <[email protected]>; pgsql-hackers
On Mon, Mar 20, 2017 at 12:07 PM, Rafia Sabih
<[email protected]> wrote:
> On a further testing of this patch I find another case when it is
> showing regression, the time taken with patch is around 160 secs and
> without it is 125 secs.
This is basically the same problem as before; the partitionwise case
is doing the hash joins with the sides flipped from the optimal
strategy. I bet that's a bug in the code rather than a problem with
the concept.
> Another minor thing to note that is planning time is almost twice with
> this patch, though I understand that this is for scenarios with really
> big 'big data' so this may not be a serious issue in such cases, but
> it'd be good if we can keep an eye on this that it doesn't exceed the
> computational bounds for a really large number of tables..
Yes, this is definitely going to use significant additional planning
time and memory. There are several possible strategies for improving
that situation, but I think we need to get the basics in place first.
That's why the proposal is now to have this turned off by default.
People joining really big tables that happen to be equipartitioned are
likely to want to turn it on, though, even before those optimizations
are done.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 277+ messages in thread
* Re: Partition-wise join for join between (declaratively) partitioned tables
2017-03-01 08:56 Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-09 01:14 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-10 10:43 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-13 19:24 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-14 12:04 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 00:33 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-15 12:49 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 19:00 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-16 10:48 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-16 15:05 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-17 10:28 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-17 13:15 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-18 00:10 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 02:51 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 16:07 ` Re: Partition-wise join for join between (declaratively) partitioned tables Rafia Sabih <[email protected]>
@ 2017-03-20 16:47 ` Ashutosh Bapat <[email protected]>
2017-03-21 11:41 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
1 sibling, 1 reply; 277+ messages in thread
From: Ashutosh Bapat @ 2017-03-20 16:47 UTC (permalink / raw)
To: Rafia Sabih <[email protected]>; +Cc: Robert Haas <[email protected]>; Rajkumar Raghuwanshi <[email protected]>; pgsql-hackers
>
> On a further testing of this patch I find another case when it is
> showing regression, the time taken with patch is around 160 secs and
> without it is 125 secs.
> Another minor thing to note that is planning time is almost twice with
> this patch, though I understand that this is for scenarios with really
> big 'big data' so this may not be a serious issue in such cases, but
> it'd be good if we can keep an eye on this that it doesn't exceed the
> computational bounds for a really large number of tables.
Right, planning time would be proportional to the number of partitions
at least in the first version. We may improve upon it later.
> Please find the attached .out file to check the output I witnessed and
> let me know if anymore information is required
> Schema and data was similar to the preciously shared schema with the
> addition of more data for this case, parameter settings used were:
> work_mem = 1GB
> random_page_cost = seq_page_cost = 0.1
The patch does not introduce any new costing model. It costs the
partition-wise join as sum of costs of joins between partitions. The
method to create the paths for joins between partitions is same as
creating the paths for joins between regular tables and then the
method to collect paths across partition-wise joins is same as
collecting paths across child base relations. So, there is a large
chance that the costing for joins between partitions might have a
problem which is showing up here. There may be some special handling
for regular tables versus child tables that may be the root cause. But
I have not seen that kind of code till now.
Can you please provide the outputs of individual partition-joins? If
the plans for joins between partitions are same as the ones chosen for
partition-wise joins, we may need to fix the existing join cost
models.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 277+ messages in thread
* Re: Partition-wise join for join between (declaratively) partitioned tables
2017-03-01 08:56 Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-09 01:14 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-10 10:43 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-13 19:24 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-14 12:04 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 00:33 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-15 12:49 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 19:00 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-16 10:48 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-16 15:05 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-17 10:28 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-17 13:15 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-18 00:10 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 02:51 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 16:07 ` Re: Partition-wise join for join between (declaratively) partitioned tables Rafia Sabih <[email protected]>
2017-03-20 16:47 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
@ 2017-03-21 11:41 ` Ashutosh Bapat <[email protected]>
2017-03-21 14:39 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
0 siblings, 1 reply; 277+ messages in thread
From: Ashutosh Bapat @ 2017-03-21 11:41 UTC (permalink / raw)
To: Rafia Sabih <[email protected]>; +Cc: Robert Haas <[email protected]>; Rajkumar Raghuwanshi <[email protected]>; pgsql-hackers
On Mon, Mar 20, 2017 at 10:17 PM, Ashutosh Bapat
<[email protected]> wrote:
>>
>> On a further testing of this patch I find another case when it is
>> showing regression, the time taken with patch is around 160 secs and
>> without it is 125 secs.
>> Another minor thing to note that is planning time is almost twice with
>> this patch, though I understand that this is for scenarios with really
>> big 'big data' so this may not be a serious issue in such cases, but
>> it'd be good if we can keep an eye on this that it doesn't exceed the
>> computational bounds for a really large number of tables.
>
> Right, planning time would be proportional to the number of partitions
> at least in the first version. We may improve upon it later.
>
>> Please find the attached .out file to check the output I witnessed and
>> let me know if anymore information is required
>> Schema and data was similar to the preciously shared schema with the
>> addition of more data for this case, parameter settings used were:
>> work_mem = 1GB
>> random_page_cost = seq_page_cost = 0.1
this doesn't look good. Why do you set both these costs to the same value?
>
> The patch does not introduce any new costing model. It costs the
> partition-wise join as sum of costs of joins between partitions. The
> method to create the paths for joins between partitions is same as
> creating the paths for joins between regular tables and then the
> method to collect paths across partition-wise joins is same as
> collecting paths across child base relations. So, there is a large
> chance that the costing for joins between partitions might have a
> problem which is showing up here. There may be some special handling
> for regular tables versus child tables that may be the root cause. But
> I have not seen that kind of code till now.
>
> Can you please provide the outputs of individual partition-joins? If
> the plans for joins between partitions are same as the ones chosen for
> partition-wise joins, we may need to fix the existing join cost
> models.
Offlist, Rafia shared the outputs of joins between partitions and join
between partitioned table. The joins between partitions look similar
to those pick up by the partition-wise join. So, it looks that some
costing error in regular joins is resulting in an costing error in
partition-wise join as suspected. Attached the SQL and the output.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Attachments:
[application/octet-stream] queries.out (110.3K, ../../CAFjFpRedUZPa7tKbCLEGK3u5UWdDNQoN=eYfb7ieG5d0D1PbsQ@mail.gmail.com/2-queries.out)
download
[application/octet-stream] queries.sql (2.9K, ../../CAFjFpRedUZPa7tKbCLEGK3u5UWdDNQoN=eYfb7ieG5d0D1PbsQ@mail.gmail.com/3-queries.sql)
download
^ permalink raw reply [nested|flat] 277+ messages in thread
* Re: Partition-wise join for join between (declaratively) partitioned tables
2017-03-01 08:56 Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-09 01:14 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-10 10:43 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-13 19:24 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-14 12:04 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 00:33 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-15 12:49 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 19:00 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-16 10:48 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-16 15:05 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-17 10:28 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-17 13:15 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-18 00:10 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 02:51 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 16:07 ` Re: Partition-wise join for join between (declaratively) partitioned tables Rafia Sabih <[email protected]>
2017-03-20 16:47 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-21 11:41 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
@ 2017-03-21 14:39 ` Robert Haas <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Robert Haas @ 2017-03-21 14:39 UTC (permalink / raw)
To: Ashutosh Bapat <[email protected]>; +Cc: Rafia Sabih <[email protected]>; Rajkumar Raghuwanshi <[email protected]>; pgsql-hackers
On Tue, Mar 21, 2017 at 7:41 AM, Ashutosh Bapat
<[email protected]> wrote:
> On Mon, Mar 20, 2017 at 10:17 PM, Ashutosh Bapat
> <[email protected]> wrote:
>>>
>>> On a further testing of this patch I find another case when it is
>>> showing regression, the time taken with patch is around 160 secs and
>>> without it is 125 secs.
>>> Another minor thing to note that is planning time is almost twice with
>>> this patch, though I understand that this is for scenarios with really
>>> big 'big data' so this may not be a serious issue in such cases, but
>>> it'd be good if we can keep an eye on this that it doesn't exceed the
>>> computational bounds for a really large number of tables.
>>
>> Right, planning time would be proportional to the number of partitions
>> at least in the first version. We may improve upon it later.
>>
>>> Please find the attached .out file to check the output I witnessed and
>>> let me know if anymore information is required
>>> Schema and data was similar to the preciously shared schema with the
>>> addition of more data for this case, parameter settings used were:
>>> work_mem = 1GB
>>> random_page_cost = seq_page_cost = 0.1
>
> this doesn't look good. Why do you set both these costs to the same value?
That's a perfectly reasonable configuration if the data is in memory
on a medium with fast random access, like an SSD.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 277+ messages in thread
* Re: Partition-wise join for join between (declaratively) partitioned tables
2017-03-01 08:56 Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-09 01:14 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-10 10:43 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-13 19:24 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-14 12:04 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 00:33 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-15 12:49 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 19:00 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-16 10:48 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-16 15:05 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-17 10:28 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-17 13:15 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-18 00:10 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
@ 2017-03-20 13:44 ` Ashutosh Bapat <[email protected]>
2017-03-20 16:28 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2 siblings, 1 reply; 277+ messages in thread
From: Ashutosh Bapat @ 2017-03-20 13:44 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: Rajkumar Raghuwanshi <[email protected]>; pgsql-hackers
On Sat, Mar 18, 2017 at 5:40 AM, Robert Haas <[email protected]> wrote:
> On Fri, Mar 17, 2017 at 9:15 AM, Ashutosh Bapat
> <[email protected]> wrote:
>> This set of patches fixes both of those things.
>
> 0001 changes the purpose of a function and then 0007 renames it. It
> would be better to include the renaming in 0001 so that you're not
> taking multiple whacks at the same function in the same patch series.
adjust_relid_set was renamed as adjust_child_relids() post
"extern"alising. I think, this comment is about that function. Done.
> I believe it would also be best to include 0011's changes to
> adjust_appendrel_attrs_multilevel in 0001.
>
The function needs to repeat the "adjustment" process for every
"other" relation (join or base) that it encounters, by testing using
OTHER_BASE_REL or OTHER_JOINREL in short IS_OTHER_REL(). The last
macros are added by the partition-wise join implementation patch 0005.
It doesn't make sense to add that macro in 0001 OR modify that
function twice, once in 0001 and then after 0005. So, I will leave it
to be part of 0011, where the changes are actually needed.
> 0002 should either add find_param_path_info() to the relevant header
> file as extern from the beginning, or it should declare and define it
> as static and then 0007 can remove those markings. It makes no sense
> to declare it as extern but put the prototype in the .c file.
Done, added find_param_path_info() as an extern definition to start
with. I have also squashed 0001 and 0002 together, since they are both
refactoring patches and from your next mail about
reparameterize_path_by_child(), it seems that we are going to accept
the approach in that patch.
>
> 0004 still needs to be pared down. If you want to get something
> committed this release cycle, you have to get these details taken care
> of, uh, more or less immediately. Actually, preferably, several weeks
> ago. You're welcome to maintain your own test suite locally but what
> you submit should be what you are proposing for commit -- or if not,
> then you should separate the part proposed for commit and the part
> included for dev testing into two different patches.
>
Done. Now SQL file has 325 lines and output has 1697 lines as against
515 and 4085 lines resp. earlier.
> In 0005's README, the part about planning partition-wise joins in two
> phases needs to be removed.
Done.
> This patch also contains a small change
> to partition_join.sql that belongs in 0004.
The reason I added the test patch prior to implementation was 1. for
me to make sure the tests that the queries run without the
optimization and the results they produce to catch any issues with
partitioning implementation. That would help someone looking at those
patches as well. 2. Once partitioning implementation patch was
applied, once could see the purpose of changes in two follow on
patches. Now that that purpose has served, I have reordered the
patches so that test patch comes after the implementation and follow
on fixes. If you still want to run the test before or after any of
those patches, you could apply the patch separately.
>
> 0008 removes direct tests against RELOPT_JOINREL almost everywhere,
> but it overlooks the new ones added to postgres_fdw.c by
> b30fb56b07a885f3476fe05920249f4832ca8da5. It should be updated to
> cover those as well, I suspect.
Done.
deparseSubqueryTargetList() and some other functions are excluding
"other" base relation from the assertions. I guess, that's a problem.
Will submit a separate patch to fix this.
> The commit message claims that it
> will "Similarly replace RELOPT_OTHER_MEMBER_REL test with
> IS_OTHER_REL() where we want to test for child relations of all kinds,
> but in fact it makes exactly zero such substitutions.
The relevant changes have been covered by other commits. Removed this
line from the commit message.
>
> While I was studying what you did with reparameterize_path_by_child(),
> I started to wonder whether reparameterize_path() doesn't need to
> start handling join paths. I think it only handles scan paths right
> now because that's the only thing that can appear under an appendrel
> created by inheritance expansion, but you're changing that. Maybe
> it's not critical -- I think the worst consequences of missing some
> handling there is that we won't consider a parameterized path in some
> case where it would be advantageous to do so. Still, you might want
> to investigate a bit.
Yes, we need to update reparameterize_path() for child-joins. A path
for child base relation gets reparameterized, if there exists a path
with that parameterization in at least one other child. The
parameterization bubbles up the join tree from base relations. So, if
a child required to be reparameterized, probably all its joins require
reparameterization, since that parameterization would bubble up the
child-join tree in which some other child participates. But as you
said it's an optimization and not a correctness issue. The function
get_cheapest_parameterized_child_path() returns NULL, if it can not
find or create a path (by reparameterization) with required
parameterization. Its caller add_paths_to_append_rel() is capable of
handling NULL values by not creating append paths with that
paramterization. If the "append" relation requires minimum
parameterization, all its children will create that minimum
parameterization, hence do not require to reparameterize path. So,
there isn't any correctness issue there.
There are two ways to fix it,
1. when we create a reparameterized path add it to the list of paths,
thus the parameterization bubbles up the join tree. But then we will
be changing the path list after set_cheapest() has been called OR may
be throwing out paths which other paths refer to. That's not
desirable. May be we can save this path in another list and create
join paths using this path instead of reparameterizing existing join
paths.
2. Add code to reparameterize_path() to handle join paths, and I think
all kinds of paths since we might have trickle the parameterization
down the joining paths which could be almost anything including
sort_paths, unique_paths etc. That looks like a significant effort. I
think, we should attack it separately after the stock partition-wise
join has been committed.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 277+ messages in thread
* Re: Partition-wise join for join between (declaratively) partitioned tables
2017-03-01 08:56 Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-09 01:14 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-10 10:43 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-13 19:24 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-14 12:04 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 00:33 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-15 12:49 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 19:00 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-16 10:48 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-16 15:05 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-17 10:28 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-17 13:15 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-18 00:10 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 13:44 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
@ 2017-03-20 16:28 ` Robert Haas <[email protected]>
2017-03-20 16:52 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
0 siblings, 1 reply; 277+ messages in thread
From: Robert Haas @ 2017-03-20 16:28 UTC (permalink / raw)
To: Ashutosh Bapat <[email protected]>; +Cc: Rajkumar Raghuwanshi <[email protected]>; pgsql-hackers
On Mon, Mar 20, 2017 at 9:44 AM, Ashutosh Bapat
<[email protected]> wrote:
>> I believe it would also be best to include 0011's changes to
>> adjust_appendrel_attrs_multilevel in 0001.
>
> The function needs to repeat the "adjustment" process for every
> "other" relation (join or base) that it encounters, by testing using
> OTHER_BASE_REL or OTHER_JOINREL in short IS_OTHER_REL(). The last
> macros are added by the partition-wise join implementation patch 0005.
> It doesn't make sense to add that macro in 0001 OR modify that
> function twice, once in 0001 and then after 0005. So, I will leave it
> to be part of 0011, where the changes are actually needed.
Hmm. I would kind of like to move the IS_JOIN_REL() and
IS_OTHER_REL() stuff to the front of the series. In other words, I
propose that we add those macros first, each testing for only the one
kind of RelOptInfo that exists today, and change all the code to use
them. Then, when we add child joinrels, we can modify the macros at
the same time. The problem with doing it the way you have it is that
those changes will have to be squashed into the main partitionwise
join commit, because otherwise stuff will be broken. Doing it the
other way around lets us commit that bit separately.
> Done. Now SQL file has 325 lines and output has 1697 lines as against
> 515 and 4085 lines resp. earlier.
Sounds reasonable.
> Now that that purpose has served, I have reordered the
> patches so that test patch comes after the implementation and follow
> on fixes.
Sounds good.
> There are two ways to fix it,
>
> 1. when we create a reparameterized path add it to the list of paths,
> thus the parameterization bubbles up the join tree. But then we will
> be changing the path list after set_cheapest() has been called OR may
> be throwing out paths which other paths refer to. That's not
> desirable. May be we can save this path in another list and create
> join paths using this path instead of reparameterizing existing join
> paths.
> 2. Add code to reparameterize_path() to handle join paths, and I think
> all kinds of paths since we might have trickle the parameterization
> down the joining paths which could be almost anything including
> sort_paths, unique_paths etc. That looks like a significant effort. I
> think, we should attack it separately after the stock partition-wise
> join has been committed.
I don't understand #1. #2 sounds like what I was expecting. I agree
it can be postponed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 277+ messages in thread
* Re: Partition-wise join for join between (declaratively) partitioned tables
2017-03-01 08:56 Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-09 01:14 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-10 10:43 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-13 19:24 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-14 12:04 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 00:33 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-15 12:49 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 19:00 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-16 10:48 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-16 15:05 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-17 10:28 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-17 13:15 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-18 00:10 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 13:44 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-20 16:28 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
@ 2017-03-20 16:52 ` Ashutosh Bapat <[email protected]>
2017-03-20 16:56 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
0 siblings, 1 reply; 277+ messages in thread
From: Ashutosh Bapat @ 2017-03-20 16:52 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: Rajkumar Raghuwanshi <[email protected]>; pgsql-hackers
>
> Hmm. I would kind of like to move the IS_JOIN_REL() and
> IS_OTHER_REL() stuff to the front of the series. In other words, I
> propose that we add those macros first, each testing for only the one
> kind of RelOptInfo that exists today, and change all the code to use
> them. Then, when we add child joinrels, we can modify the macros at
> the same time. The problem with doing it the way you have it is that
> those changes will have to be squashed into the main partitionwise
> join commit, because otherwise stuff will be broken. Doing it the
> other way around lets us commit that bit separately.
>
I can provide a patch with adjust_appendrel_attrs_multilevel() changed
to child-joins, which can be applied before multi-level
partitioin-wise support patch but after partition-wise implementation
patch. You may consider applying that patch separately before
multi-level partition-wise support, in case we see that multi-level
partition-wise join support can be committed. Does that sound good?
That way we save changing those macros twice.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 277+ messages in thread
* Re: Partition-wise join for join between (declaratively) partitioned tables
2017-03-01 08:56 Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-09 01:14 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-10 10:43 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-13 19:24 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-14 12:04 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 00:33 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-15 12:49 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 19:00 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-16 10:48 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-16 15:05 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-17 10:28 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-17 13:15 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-18 00:10 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 13:44 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-20 16:28 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 16:52 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
@ 2017-03-20 16:56 ` Robert Haas <[email protected]>
2017-03-20 17:19 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
0 siblings, 1 reply; 277+ messages in thread
From: Robert Haas @ 2017-03-20 16:56 UTC (permalink / raw)
To: Ashutosh Bapat <[email protected]>; +Cc: Rajkumar Raghuwanshi <[email protected]>; pgsql-hackers
On Mon, Mar 20, 2017 at 12:52 PM, Ashutosh Bapat
<[email protected]> wrote:
>> Hmm. I would kind of like to move the IS_JOIN_REL() and
>> IS_OTHER_REL() stuff to the front of the series. In other words, I
>> propose that we add those macros first, each testing for only the one
>> kind of RelOptInfo that exists today, and change all the code to use
>> them. Then, when we add child joinrels, we can modify the macros at
>> the same time. The problem with doing it the way you have it is that
>> those changes will have to be squashed into the main partitionwise
>> join commit, because otherwise stuff will be broken. Doing it the
>> other way around lets us commit that bit separately.
>
> I can provide a patch with adjust_appendrel_attrs_multilevel() changed
> to child-joins, which can be applied before multi-level
> partitioin-wise support patch but after partition-wise implementation
> patch. You may consider applying that patch separately before
> multi-level partition-wise support, in case we see that multi-level
> partition-wise join support can be committed. Does that sound good?
> That way we save changing those macros twice.
That seems different than what I suggested and I'm not sure what the
reason is for the difference?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 277+ messages in thread
* Re: Partition-wise join for join between (declaratively) partitioned tables
2017-03-01 08:56 Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-09 01:14 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-10 10:43 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-13 19:24 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-14 12:04 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 00:33 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-15 12:49 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 19:00 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-16 10:48 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-16 15:05 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-17 10:28 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-17 13:15 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-18 00:10 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 13:44 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-20 16:28 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 16:52 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-20 16:56 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
@ 2017-03-20 17:19 ` Ashutosh Bapat <[email protected]>
2017-03-20 18:03 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
0 siblings, 1 reply; 277+ messages in thread
From: Ashutosh Bapat @ 2017-03-20 17:19 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: Rajkumar Raghuwanshi <[email protected]>; pgsql-hackers
On Mon, Mar 20, 2017 at 10:26 PM, Robert Haas <[email protected]> wrote:
> On Mon, Mar 20, 2017 at 12:52 PM, Ashutosh Bapat
> <[email protected]> wrote:
>>> Hmm. I would kind of like to move the IS_JOIN_REL() and
>>> IS_OTHER_REL() stuff to the front of the series. In other words, I
>>> propose that we add those macros first, each testing for only the one
>>> kind of RelOptInfo that exists today, and change all the code to use
>>> them. Then, when we add child joinrels, we can modify the macros at
>>> the same time. The problem with doing it the way you have it is that
>>> those changes will have to be squashed into the main partitionwise
>>> join commit, because otherwise stuff will be broken. Doing it the
>>> other way around lets us commit that bit separately.
>>
>> I can provide a patch with adjust_appendrel_attrs_multilevel() changed
>> to child-joins, which can be applied before multi-level
>> partitioin-wise support patch but after partition-wise implementation
>> patch. You may consider applying that patch separately before
>> multi-level partition-wise support, in case we see that multi-level
>> partition-wise join support can be committed. Does that sound good?
>> That way we save changing those macros twice.
>
> That seems different than what I suggested and I'm not sure what the
> reason is for the difference?
>
The patch adding macros IS_JOIN_REL() and IS_OTHER_REL() and changing
the code to use it will look quite odd by itself. We are not changing
all the instances of RELOPT_JOINREL or RELOPT_OTHER_MEMBER_REL to use
those. There is code which needs to check those kinds, instead of "all
join rels" or "all other rels" resp. So the patch will add those
macros, change only few places to use those macros, which are intended
to be changed while applying partition-wise join support for single
level partitioned table.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 277+ messages in thread
* Re: Partition-wise join for join between (declaratively) partitioned tables
2017-03-01 08:56 Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-09 01:14 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-10 10:43 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-13 19:24 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-14 12:04 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 00:33 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-15 12:49 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 19:00 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-16 10:48 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-16 15:05 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-17 10:28 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-17 13:15 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-18 00:10 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 13:44 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-20 16:28 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 16:52 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-20 16:56 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 17:19 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
@ 2017-03-20 18:03 ` Robert Haas <[email protected]>
2017-03-21 10:22 ` Re: Partition-wise join for join between (declaratively) partitioned tables Rajkumar Raghuwanshi <[email protected]>
2017-03-21 11:46 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
0 siblings, 2 replies; 277+ messages in thread
From: Robert Haas @ 2017-03-20 18:03 UTC (permalink / raw)
To: Ashutosh Bapat <[email protected]>; +Cc: Rajkumar Raghuwanshi <[email protected]>; pgsql-hackers
On Mon, Mar 20, 2017 at 1:19 PM, Ashutosh Bapat
<[email protected]> wrote:
>> That seems different than what I suggested and I'm not sure what the
>> reason is for the difference?
>
> The patch adding macros IS_JOIN_REL() and IS_OTHER_REL() and changing
> the code to use it will look quite odd by itself. We are not changing
> all the instances of RELOPT_JOINREL or RELOPT_OTHER_MEMBER_REL to use
> those. There is code which needs to check those kinds, instead of "all
> join rels" or "all other rels" resp. So the patch will add those
> macros, change only few places to use those macros, which are intended
> to be changed while applying partition-wise join support for single
> level partitioned table.
Hmm. You might be right, but I'm not convinced.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 277+ messages in thread
* Re: Partition-wise join for join between (declaratively) partitioned tables
2017-03-01 08:56 Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-09 01:14 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-10 10:43 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-13 19:24 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-14 12:04 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 00:33 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-15 12:49 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 19:00 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-16 10:48 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-16 15:05 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-17 10:28 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-17 13:15 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-18 00:10 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 13:44 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-20 16:28 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 16:52 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-20 16:56 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 17:19 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-20 18:03 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
@ 2017-03-21 10:22 ` Rajkumar Raghuwanshi <[email protected]>
2017-03-21 14:19 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
1 sibling, 1 reply; 277+ messages in thread
From: Rajkumar Raghuwanshi @ 2017-03-21 10:22 UTC (permalink / raw)
To: Ashutosh Bapat <[email protected]>; +Cc: pgsql-hackers; Robert Haas <[email protected]>
> On Mon, Mar 20, 2017 at 1:19 PM, Ashutosh Bapat
> <[email protected]> wrote:
I have created some test to cover partition wise joins with
postgres_fdw, also verified make check.
patch attached.
Thanks & Regards,
Rajkumar Raghuwanshi
QMG, EnterpriseDB Corporation
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Attachments:
[text/x-patch] postgres_fdw_pwj.patch (10.2K, ../../CAKcux6kJzGjwRw+trL2x_nQwevJppZVK5MJzwcy6mYQV4fBnZA@mail.gmail.com/2-postgres_fdw_pwj.patch)
download | inline diff:
diff --git a/contrib/postgres_fdw/expected/postgres_fdw.out b/contrib/postgres_fdw/expected/postgres_fdw.out
index 059c5c3..f0b1a32 100644
--- a/contrib/postgres_fdw/expected/postgres_fdw.out
+++ b/contrib/postgres_fdw/expected/postgres_fdw.out
@@ -7181,3 +7181,149 @@ AND ftoptions @> array['fetch_size=60000'];
(1 row)
ROLLBACK;
+-- ===================================================================
+-- test partition-wise-joins
+-- ===================================================================
+SET enable_partition_wise_join=on;
+--range partition
+CREATE TABLE fprt1 (a int, b int, c varchar) PARTITION BY RANGE(a);
+CREATE TABLE fprt1_p1 (a int, b int, c text);
+CREATE TABLE fprt1_p2 (a int, b int, c text);
+CREATE FOREIGN TABLE ftprt1_p1 PARTITION OF fprt1 FOR VALUES FROM (0) TO (250)
+SERVER loopback OPTIONS (TABLE_NAME 'fprt1_p1');
+CREATE FOREIGN TABLE ftprt1_p2 PARTITION OF fprt1 FOR VALUES FROM (250) TO (500)
+SERVER loopback OPTIONS (TABLE_NAME 'fprt1_p2');
+INSERT INTO fprt1_p1 SELECT i, i, to_char(i/50, 'FM0000') FROM generate_series(0, 249, 2) i;
+INSERT INTO fprt1_p2 SELECT i, i, to_char(i/50, 'FM0000') FROM generate_series(250, 499, 2) i;
+ANALYZE fprt1;
+CREATE TABLE fprt2 (a int, b int, c varchar) PARTITION BY RANGE(b);
+CREATE TABLE fprt2_p1 (a int, b int, c text);
+CREATE TABLE fprt2_p2 (a int, b int, c text);
+CREATE FOREIGN TABLE ftprt2_p1 PARTITION OF fprt2 FOR VALUES FROM (0) TO (250)
+SERVER loopback OPTIONS (TABLE_NAME 'fprt2_p1');
+CREATE FOREIGN TABLE ftprt2_p2 PARTITION OF fprt2 FOR VALUES FROM (250) TO (500)
+SERVER loopback OPTIONS (TABLE_NAME 'fprt2_p2');
+INSERT INTO fprt2_p1 SELECT i, i, to_char(i/50, 'FM0000') FROM generate_series(0, 249, 3) i;
+INSERT INTO fprt2_p2 SELECT i, i, to_char(i/50, 'FM0000') FROM generate_series(250, 499, 3) i;
+ANALYZE fprt2;
+-- inner join three tables, all join qualified
+EXPLAIN (COSTS OFF)
+SELECT t1.a,t2.b,t3.c FROM fprt1 t1 INNER JOIN fprt2 t2 ON (t1.a = t2.b) INNER JOIN fprt1 t3 ON (t2.b = t3.a) WHERE t1.a % 25 =0 ORDER BY 1,2,3;
+ QUERY PLAN
+--------------------------------------------------------------------------------------------------------------------
+ Sort
+ Sort Key: t1.a, t3.c
+ -> Append
+ -> Foreign Scan
+ Relations: ((public.ftprt1_p1 t1) INNER JOIN (public.ftprt2_p1 t2)) INNER JOIN (public.ftprt1_p1 t3)
+ -> Foreign Scan
+ Relations: ((public.ftprt1_p2 t1) INNER JOIN (public.ftprt2_p2 t2)) INNER JOIN (public.ftprt1_p2 t3)
+(7 rows)
+
+SELECT t1.a,t2.b,t3.c FROM fprt1 t1 INNER JOIN fprt2 t2 ON (t1.a = t2.b) INNER JOIN fprt1 t3 ON (t2.b = t3.a) WHERE t1.a % 25 =0 ORDER BY 1,2,3;
+ a | b | c
+-----+-----+------
+ 0 | 0 | 0000
+ 150 | 150 | 0003
+ 250 | 250 | 0005
+ 400 | 400 | 0008
+(4 rows)
+
+-- left outer join + nullable clasue
+EXPLAIN (COSTS OFF)
+SELECT t1.a,t2.b,t2.c FROM fprt1 t1 LEFT JOIN (SELECT * FROM fprt2 WHERE a < 10) t2 ON (t1.a = t2.b and t1.b = t2.a) WHERE t1.a < 10 ORDER BY 1,2,3;
+ QUERY PLAN
+-----------------------------------------------------------------------------
+ Merge Append
+ Sort Key: t1.a, ftprt2_p1.b, ftprt2_p1.c
+ -> Foreign Scan
+ Relations: (public.ftprt1_p1 t1) LEFT JOIN (public.ftprt2_p1 fprt2)
+(4 rows)
+
+SELECT t1.a,t2.b,t2.c FROM fprt1 t1 LEFT JOIN (SELECT * FROM fprt2 WHERE a < 10) t2 ON (t1.a = t2.b and t1.b = t2.a) WHERE t1.a < 10 ORDER BY 1,2,3;
+ a | b | c
+---+---+------
+ 0 | 0 | 0000
+ 2 | |
+ 4 | |
+ 6 | 6 | 0000
+ 8 | |
+(5 rows)
+
+-- full outer join + right outer join
+EXPLAIN (COSTS OFF)
+SELECT t1.a,t2.b,t3.c FROM fprt1 t1 FULL JOIN fprt2 t2 ON (t1.a = t2.b and t1.b = t2.a) RIGHT JOIN fprt1 t3 ON (t2.a = t3.b and t2.a = t3.b) WHERE t1.a % 25 =0 ORDER BY 1,2,3;
+ QUERY PLAN
+---------------------------------------------------------------------------------------------
+ Sort
+ Sort Key: t1.a, t3.c
+ -> Hash Join
+ Hash Cond: (t3.b = t1.b)
+ -> Append
+ -> Seq Scan on fprt1 t3
+ -> Foreign Scan on ftprt1_p1 t3_1
+ -> Foreign Scan on ftprt1_p2 t3_2
+ -> Hash
+ -> Append
+ -> Foreign Scan
+ Relations: (public.ftprt1_p1 t1) INNER JOIN (public.ftprt2_p1 t2)
+ -> Foreign Scan
+ Relations: (public.ftprt1_p2 t1) INNER JOIN (public.ftprt2_p2 t2)
+(14 rows)
+
+SELECT t1.a,t2.b,t3.c FROM fprt1 t1 FULL JOIN fprt2 t2 ON (t1.a = t2.b and t1.b = t2.a) RIGHT JOIN fprt1 t3 ON (t2.a = t3.b and t2.a = t3.b) WHERE t1.a % 25 =0 ORDER BY 1,2,3;
+ a | b | c
+-----+-----+------
+ 0 | 0 | 0000
+ 150 | 150 | 0003
+ 250 | 250 | 0005
+ 400 | 400 | 0008
+(4 rows)
+
+-- with whole-row reference
+EXPLAIN (COSTS OFF)
+SELECT t1,t2 FROM fprt1 t1 JOIN fprt2 t2 ON (t1.a = t2.b and t1.b = t2.a) WHERE t1.a % 25 =0 ORDER BY 1,2;
+ QUERY PLAN
+---------------------------------------------------------------------------------
+ Sort
+ Sort Key: ((t1.*)::fprt1), ((t2.*)::fprt2)
+ -> Append
+ -> Foreign Scan
+ Relations: (public.ftprt1_p1 t1) INNER JOIN (public.ftprt2_p1 t2)
+ -> Foreign Scan
+ Relations: (public.ftprt1_p2 t1) INNER JOIN (public.ftprt2_p2 t2)
+(7 rows)
+
+SELECT t1,t2 FROM fprt1 t1 JOIN fprt2 t2 ON (t1.a = t2.b and t1.b = t2.a) WHERE t1.a % 25 =0 ORDER BY 1,2;
+ t1 | t2
+----------------+----------------
+ (0,0,0000) | (0,0,0000)
+ (150,150,0003) | (150,150,0003)
+ (250,250,0005) | (250,250,0005)
+ (400,400,0008) | (400,400,0008)
+(4 rows)
+
+-- join with lateral reference
+EXPLAIN (COSTS OFF)
+SELECT t1.a,t1.b FROM fprt1 t1, LATERAL (SELECT t2.a, t2.b FROM fprt2 t2 WHERE t1.a = t2.b AND t1.b = t2.a) q WHERE t1.a%25 = 0 ORDER BY 1,2;
+ QUERY PLAN
+---------------------------------------------------------------------------------
+ Sort
+ Sort Key: t1.a, t1.b
+ -> Append
+ -> Foreign Scan
+ Relations: (public.ftprt1_p1 t1) INNER JOIN (public.ftprt2_p1 t2)
+ -> Foreign Scan
+ Relations: (public.ftprt1_p2 t1) INNER JOIN (public.ftprt2_p2 t2)
+(7 rows)
+
+SELECT t1.a,t1.b FROM fprt1 t1, LATERAL (SELECT t2.a, t2.b FROM fprt2 t2 WHERE t1.a = t2.b AND t1.b = t2.a) q WHERE t1.a%25 = 0 ORDER BY 1,2;
+ a | b
+-----+-----
+ 0 | 0
+ 150 | 150
+ 250 | 250
+ 400 | 400
+(4 rows)
+
+RESET enable_partition_wise_join;
diff --git a/contrib/postgres_fdw/sql/postgres_fdw.sql b/contrib/postgres_fdw/sql/postgres_fdw.sql
index 8f3edc1..2ac21e6 100644
--- a/contrib/postgres_fdw/sql/postgres_fdw.sql
+++ b/contrib/postgres_fdw/sql/postgres_fdw.sql
@@ -1706,3 +1706,58 @@ WHERE ftrelid = 'table30000'::regclass
AND ftoptions @> array['fetch_size=60000'];
ROLLBACK;
+
+-- ===================================================================
+-- test partition-wise-joins
+-- ===================================================================
+SET enable_partition_wise_join=on;
+
+--range partition
+CREATE TABLE fprt1 (a int, b int, c varchar) PARTITION BY RANGE(a);
+CREATE TABLE fprt1_p1 (a int, b int, c text);
+CREATE TABLE fprt1_p2 (a int, b int, c text);
+CREATE FOREIGN TABLE ftprt1_p1 PARTITION OF fprt1 FOR VALUES FROM (0) TO (250)
+SERVER loopback OPTIONS (TABLE_NAME 'fprt1_p1');
+CREATE FOREIGN TABLE ftprt1_p2 PARTITION OF fprt1 FOR VALUES FROM (250) TO (500)
+SERVER loopback OPTIONS (TABLE_NAME 'fprt1_p2');
+INSERT INTO fprt1_p1 SELECT i, i, to_char(i/50, 'FM0000') FROM generate_series(0, 249, 2) i;
+INSERT INTO fprt1_p2 SELECT i, i, to_char(i/50, 'FM0000') FROM generate_series(250, 499, 2) i;
+ANALYZE fprt1;
+
+CREATE TABLE fprt2 (a int, b int, c varchar) PARTITION BY RANGE(b);
+CREATE TABLE fprt2_p1 (a int, b int, c text);
+CREATE TABLE fprt2_p2 (a int, b int, c text);
+CREATE FOREIGN TABLE ftprt2_p1 PARTITION OF fprt2 FOR VALUES FROM (0) TO (250)
+SERVER loopback OPTIONS (TABLE_NAME 'fprt2_p1');
+CREATE FOREIGN TABLE ftprt2_p2 PARTITION OF fprt2 FOR VALUES FROM (250) TO (500)
+SERVER loopback OPTIONS (TABLE_NAME 'fprt2_p2');
+INSERT INTO fprt2_p1 SELECT i, i, to_char(i/50, 'FM0000') FROM generate_series(0, 249, 3) i;
+INSERT INTO fprt2_p2 SELECT i, i, to_char(i/50, 'FM0000') FROM generate_series(250, 499, 3) i;
+ANALYZE fprt2;
+
+-- inner join three tables, all join qualified
+EXPLAIN (COSTS OFF)
+SELECT t1.a,t2.b,t3.c FROM fprt1 t1 INNER JOIN fprt2 t2 ON (t1.a = t2.b) INNER JOIN fprt1 t3 ON (t2.b = t3.a) WHERE t1.a % 25 =0 ORDER BY 1,2,3;
+SELECT t1.a,t2.b,t3.c FROM fprt1 t1 INNER JOIN fprt2 t2 ON (t1.a = t2.b) INNER JOIN fprt1 t3 ON (t2.b = t3.a) WHERE t1.a % 25 =0 ORDER BY 1,2,3;
+
+-- left outer join + nullable clasue
+EXPLAIN (COSTS OFF)
+SELECT t1.a,t2.b,t2.c FROM fprt1 t1 LEFT JOIN (SELECT * FROM fprt2 WHERE a < 10) t2 ON (t1.a = t2.b and t1.b = t2.a) WHERE t1.a < 10 ORDER BY 1,2,3;
+SELECT t1.a,t2.b,t2.c FROM fprt1 t1 LEFT JOIN (SELECT * FROM fprt2 WHERE a < 10) t2 ON (t1.a = t2.b and t1.b = t2.a) WHERE t1.a < 10 ORDER BY 1,2,3;
+
+-- full outer join + right outer join
+EXPLAIN (COSTS OFF)
+SELECT t1.a,t2.b,t3.c FROM fprt1 t1 FULL JOIN fprt2 t2 ON (t1.a = t2.b and t1.b = t2.a) RIGHT JOIN fprt1 t3 ON (t2.a = t3.b and t2.a = t3.b) WHERE t1.a % 25 =0 ORDER BY 1,2,3;
+SELECT t1.a,t2.b,t3.c FROM fprt1 t1 FULL JOIN fprt2 t2 ON (t1.a = t2.b and t1.b = t2.a) RIGHT JOIN fprt1 t3 ON (t2.a = t3.b and t2.a = t3.b) WHERE t1.a % 25 =0 ORDER BY 1,2,3;
+
+-- with whole-row reference
+EXPLAIN (COSTS OFF)
+SELECT t1,t2 FROM fprt1 t1 JOIN fprt2 t2 ON (t1.a = t2.b and t1.b = t2.a) WHERE t1.a % 25 =0 ORDER BY 1,2;
+SELECT t1,t2 FROM fprt1 t1 JOIN fprt2 t2 ON (t1.a = t2.b and t1.b = t2.a) WHERE t1.a % 25 =0 ORDER BY 1,2;
+
+-- join with lateral reference
+EXPLAIN (COSTS OFF)
+SELECT t1.a,t1.b FROM fprt1 t1, LATERAL (SELECT t2.a, t2.b FROM fprt2 t2 WHERE t1.a = t2.b AND t1.b = t2.a) q WHERE t1.a%25 = 0 ORDER BY 1,2;
+SELECT t1.a,t1.b FROM fprt1 t1, LATERAL (SELECT t2.a, t2.b FROM fprt2 t2 WHERE t1.a = t2.b AND t1.b = t2.a) q WHERE t1.a%25 = 0 ORDER BY 1,2;
+
+RESET enable_partition_wise_join;
^ permalink raw reply [nested|flat] 277+ messages in thread
* Re: Partition-wise join for join between (declaratively) partitioned tables
2017-03-01 08:56 Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-09 01:14 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-10 10:43 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-13 19:24 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-14 12:04 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 00:33 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-15 12:49 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 19:00 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-16 10:48 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-16 15:05 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-17 10:28 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-17 13:15 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-18 00:10 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 13:44 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-20 16:28 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 16:52 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-20 16:56 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 17:19 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-20 18:03 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-21 10:22 ` Re: Partition-wise join for join between (declaratively) partitioned tables Rajkumar Raghuwanshi <[email protected]>
@ 2017-03-21 14:19 ` Ashutosh Bapat <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Ashutosh Bapat @ 2017-03-21 14:19 UTC (permalink / raw)
To: Rajkumar Raghuwanshi <[email protected]>; +Cc: pgsql-hackers; Robert Haas <[email protected]>
Thanks Rajkumar. Added those in the latest set of patches.
On Tue, Mar 21, 2017 at 3:52 PM, Rajkumar Raghuwanshi
<[email protected]> wrote:
>> On Mon, Mar 20, 2017 at 1:19 PM, Ashutosh Bapat
>> <[email protected]> wrote:
>
> I have created some test to cover partition wise joins with
> postgres_fdw, also verified make check.
> patch attached.
>
> Thanks & Regards,
> Rajkumar Raghuwanshi
> QMG, EnterpriseDB Corporation
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 277+ messages in thread
* Re: Partition-wise join for join between (declaratively) partitioned tables
2017-03-01 08:56 Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-09 01:14 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-10 10:43 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-13 19:24 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-14 12:04 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 00:33 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-15 12:49 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 19:00 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-16 10:48 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-16 15:05 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-17 10:28 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-17 13:15 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-18 00:10 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 13:44 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-20 16:28 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 16:52 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-20 16:56 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 17:19 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-20 18:03 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
@ 2017-03-21 11:46 ` Ashutosh Bapat <[email protected]>
2017-03-21 17:10 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
1 sibling, 1 reply; 277+ messages in thread
From: Ashutosh Bapat @ 2017-03-21 11:46 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: Rajkumar Raghuwanshi <[email protected]>; pgsql-hackers
On Mon, Mar 20, 2017 at 11:33 PM, Robert Haas <[email protected]> wrote:
> On Mon, Mar 20, 2017 at 1:19 PM, Ashutosh Bapat
> <[email protected]> wrote:
>>> That seems different than what I suggested and I'm not sure what the
>>> reason is for the difference?
>>
>> The patch adding macros IS_JOIN_REL() and IS_OTHER_REL() and changing
>> the code to use it will look quite odd by itself. We are not changing
>> all the instances of RELOPT_JOINREL or RELOPT_OTHER_MEMBER_REL to use
>> those. There is code which needs to check those kinds, instead of "all
>> join rels" or "all other rels" resp. So the patch will add those
>> macros, change only few places to use those macros, which are intended
>> to be changed while applying partition-wise join support for single
>> level partitioned table.
>
> Hmm. You might be right, but I'm not convinced.
Ok. changed as per your request in the latest set of patches.
There are some more changes as follows
1. In the earlier patch set the changes related to
calc_nestloop_required_outer() and related functions were spread
across multiple patches. That was unintentional. This patch set has
all those changes in a single patch.
2. Rajkumar reported a crash offlist. When one of the joining
multi-level partitioned relations is empty, an assertion in
try_partition_wise_join() Assert(rel1->part_rels && rel2->part_rels);
failed since it didn't find part_rels for a subpartition. The problem
here is set_append_rel_size() does not call set_rel_size() and hence
set_append_rel_size() if a child is found to be empty, a scenario
described in [1]. It's the later one which sets the part_rels for a
partitioned relation and hence the subpartitions do not get part_rels
since set_append_rel_size() is never called for those. Generally, if a
partitioned relation is found to be empty before we set part_rels, we
may not want to spend time in creating/collecting child RelOptInfos,
since they will be empty anyway. If part_rels isn't present,
part_scheme doesn't make sense. So an empty partitioned table without
any partitions can be treated as unpartitioned. So, I have fixed
set_dummy_rel_pathlist() and mark_dummy_rel(), the functions setting a
relation empty, to reset partition scheme when those conditions are
met. This fix is included as a separate patch. Let me know if this
looks good to you.
3. I am in the process of completing reparameterize_paths_by_child()
by adding all possible paths. I have restructured the function to look
better and have one switch case instead of two. Also added more path
types including ForeignPath, for which I have added a FDW hook, with
documentation, for handling fdw_private. Please let me know if this
looks good to you. I am thinking of similar hook for CustomPath. I
will continue to add more path types to
reparameterize_path_by_child().
I am wondering whether we should bring 0007 he patche adjusting code
to work with child-joins before 0006, partition-wise join. 0006 needs
it, but 0007 doesn't depend upon 0006. Will that be any better?
[1] CAFjFpRcdrdsCRDbBu0J2pxwWbhb_sDWQUTVznBy_4XGr-p3+wA@mail.gmail.com,
subject "Asymmetry between parent and child wrt "false" quals"
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Attachments:
[application/zip] pg_dp_join_patches_v9.zip (59.7K, ../../CAFjFpRe6P4-qs0LP3ZmME8r5Ech+qJ5Tg7xfLkKKFJqs2bZtPA@mail.gmail.com/2-pg_dp_join_patches_v9.zip)
download
^ permalink raw reply [nested|flat] 277+ messages in thread
* Re: Partition-wise join for join between (declaratively) partitioned tables
2017-03-01 08:56 Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-09 01:14 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-10 10:43 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-13 19:24 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-14 12:04 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 00:33 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-15 12:49 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 19:00 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-16 10:48 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-16 15:05 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-17 10:28 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-17 13:15 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-18 00:10 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 13:44 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-20 16:28 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 16:52 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-20 16:56 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 17:19 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-20 18:03 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-21 11:46 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
@ 2017-03-21 17:10 ` Ashutosh Bapat <[email protected]>
2017-03-22 08:17 ` Re: Partition-wise join for join between (declaratively) partitioned tables Rafia Sabih <[email protected]>
0 siblings, 1 reply; 277+ messages in thread
From: Ashutosh Bapat @ 2017-03-21 17:10 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: Rajkumar Raghuwanshi <[email protected]>; pgsql-hackers
Here's the set of patches rebased on latest head, which also has a
commit to eliminate scans on partitioned tables. This change has
caused problems with multi-level partitioned tables, that I have not
fixed in this patch set. Also a couple of partition-wise join plans
for single-level partitioned tables have changed to non-partition-wise
joins. I haven't fixed those as well.
I have added a separate patch to fix add_paths_to_append_rel() to
collect partitioned_rels list for join relations. Please let me know
if this looks good. I think it needs to be merged into some other
patch, but I am not sure which. Probably we should just treat it as
another refactoring patch.
On Tue, Mar 21, 2017 at 5:16 PM, Ashutosh Bapat
<[email protected]> wrote:
> On Mon, Mar 20, 2017 at 11:33 PM, Robert Haas <[email protected]> wrote:
>> On Mon, Mar 20, 2017 at 1:19 PM, Ashutosh Bapat
>> <[email protected]> wrote:
>>>> That seems different than what I suggested and I'm not sure what the
>>>> reason is for the difference?
>>>
>>> The patch adding macros IS_JOIN_REL() and IS_OTHER_REL() and changing
>>> the code to use it will look quite odd by itself. We are not changing
>>> all the instances of RELOPT_JOINREL or RELOPT_OTHER_MEMBER_REL to use
>>> those. There is code which needs to check those kinds, instead of "all
>>> join rels" or "all other rels" resp. So the patch will add those
>>> macros, change only few places to use those macros, which are intended
>>> to be changed while applying partition-wise join support for single
>>> level partitioned table.
>>
>> Hmm. You might be right, but I'm not convinced.
>
> Ok. changed as per your request in the latest set of patches.
>
> There are some more changes as follows
> 1. In the earlier patch set the changes related to
> calc_nestloop_required_outer() and related functions were spread
> across multiple patches. That was unintentional. This patch set has
> all those changes in a single patch.
>
> 2. Rajkumar reported a crash offlist. When one of the joining
> multi-level partitioned relations is empty, an assertion in
> try_partition_wise_join() Assert(rel1->part_rels && rel2->part_rels);
> failed since it didn't find part_rels for a subpartition. The problem
> here is set_append_rel_size() does not call set_rel_size() and hence
> set_append_rel_size() if a child is found to be empty, a scenario
> described in [1]. It's the later one which sets the part_rels for a
> partitioned relation and hence the subpartitions do not get part_rels
> since set_append_rel_size() is never called for those. Generally, if a
> partitioned relation is found to be empty before we set part_rels, we
> may not want to spend time in creating/collecting child RelOptInfos,
> since they will be empty anyway. If part_rels isn't present,
> part_scheme doesn't make sense. So an empty partitioned table without
> any partitions can be treated as unpartitioned. So, I have fixed
> set_dummy_rel_pathlist() and mark_dummy_rel(), the functions setting a
> relation empty, to reset partition scheme when those conditions are
> met. This fix is included as a separate patch. Let me know if this
> looks good to you.
>
> 3. I am in the process of completing reparameterize_paths_by_child()
> by adding all possible paths. I have restructured the function to look
> better and have one switch case instead of two. Also added more path
> types including ForeignPath, for which I have added a FDW hook, with
> documentation, for handling fdw_private. Please let me know if this
> looks good to you. I am thinking of similar hook for CustomPath. I
> will continue to add more path types to
> reparameterize_path_by_child().
>
> I am wondering whether we should bring 0007 he patche adjusting code
> to work with child-joins before 0006, partition-wise join. 0006 needs
> it, but 0007 doesn't depend upon 0006. Will that be any better?
>
> [1] CAFjFpRcdrdsCRDbBu0J2pxwWbhb_sDWQUTVznBy_4XGr-p3+wA@mail.gmail.com,
> subject "Asymmetry between parent and child wrt "false" quals"
>
> --
> Best Wishes,
> Ashutosh Bapat
> EnterpriseDB Corporation
> The Postgres Database Company
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Attachments:
[application/zip] pg_dp_join_patches_v11.zip (60.0K, ../../CAFjFpRcqxDx4k-G0MgiufN7+2CgpmxKsHDw-vt4Q5Nt9L3XmQA@mail.gmail.com/2-pg_dp_join_patches_v11.zip)
download
^ permalink raw reply [nested|flat] 277+ messages in thread
* Re: Partition-wise join for join between (declaratively) partitioned tables
2017-03-01 08:56 Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-09 01:14 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-10 10:43 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-13 19:24 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-14 12:04 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 00:33 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-15 12:49 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 19:00 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-16 10:48 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-16 15:05 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-17 10:28 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-17 13:15 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-18 00:10 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 13:44 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-20 16:28 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 16:52 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-20 16:56 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 17:19 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-20 18:03 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-21 11:46 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-21 17:10 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
@ 2017-03-22 08:17 ` Rafia Sabih <[email protected]>
2017-03-22 09:49 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
0 siblings, 1 reply; 277+ messages in thread
From: Rafia Sabih @ 2017-03-22 08:17 UTC (permalink / raw)
To: Ashutosh Bapat <[email protected]>; +Cc: Robert Haas <[email protected]>; Rajkumar Raghuwanshi <[email protected]>; pgsql-hackers
On Tue, Mar 21, 2017 at 10:40 PM, Ashutosh Bapat
<[email protected]> wrote:
> Here's the set of patches rebased on latest head, which also has a
> commit to eliminate scans on partitioned tables. This change has
> caused problems with multi-level partitioned tables, that I have not
> fixed in this patch set. Also a couple of partition-wise join plans
> for single-level partitioned tables have changed to non-partition-wise
> joins. I haven't fixed those as well.
>
> I have added a separate patch to fix add_paths_to_append_rel() to
> collect partitioned_rels list for join relations. Please let me know
> if this looks good. I think it needs to be merged into some other
> patch, but I am not sure which. Probably we should just treat it as
> another refactoring patch.
>
> On Tue, Mar 21, 2017 at 5:16 PM, Ashutosh Bapat
> <[email protected]> wrote:
>> On Mon, Mar 20, 2017 at 11:33 PM, Robert Haas <[email protected]> wrote:
>>> On Mon, Mar 20, 2017 at 1:19 PM, Ashutosh Bapat
>>> <[email protected]> wrote:
>>>>> That seems different than what I suggested and I'm not sure what the
>>>>> reason is for the difference?
>>>>
>>>> The patch adding macros IS_JOIN_REL() and IS_OTHER_REL() and changing
>>>> the code to use it will look quite odd by itself. We are not changing
>>>> all the instances of RELOPT_JOINREL or RELOPT_OTHER_MEMBER_REL to use
>>>> those. There is code which needs to check those kinds, instead of "all
>>>> join rels" or "all other rels" resp. So the patch will add those
>>>> macros, change only few places to use those macros, which are intended
>>>> to be changed while applying partition-wise join support for single
>>>> level partitioned table.
>>>
>>> Hmm. You might be right, but I'm not convinced.
>>
>> Ok. changed as per your request in the latest set of patches.
>>
>> There are some more changes as follows
>> 1. In the earlier patch set the changes related to
>> calc_nestloop_required_outer() and related functions were spread
>> across multiple patches. That was unintentional. This patch set has
>> all those changes in a single patch.
>>
>> 2. Rajkumar reported a crash offlist. When one of the joining
>> multi-level partitioned relations is empty, an assertion in
>> try_partition_wise_join() Assert(rel1->part_rels && rel2->part_rels);
>> failed since it didn't find part_rels for a subpartition. The problem
>> here is set_append_rel_size() does not call set_rel_size() and hence
>> set_append_rel_size() if a child is found to be empty, a scenario
>> described in [1]. It's the later one which sets the part_rels for a
>> partitioned relation and hence the subpartitions do not get part_rels
>> since set_append_rel_size() is never called for those. Generally, if a
>> partitioned relation is found to be empty before we set part_rels, we
>> may not want to spend time in creating/collecting child RelOptInfos,
>> since they will be empty anyway. If part_rels isn't present,
>> part_scheme doesn't make sense. So an empty partitioned table without
>> any partitions can be treated as unpartitioned. So, I have fixed
>> set_dummy_rel_pathlist() and mark_dummy_rel(), the functions setting a
>> relation empty, to reset partition scheme when those conditions are
>> met. This fix is included as a separate patch. Let me know if this
>> looks good to you.
>>
>> 3. I am in the process of completing reparameterize_paths_by_child()
>> by adding all possible paths. I have restructured the function to look
>> better and have one switch case instead of two. Also added more path
>> types including ForeignPath, for which I have added a FDW hook, with
>> documentation, for handling fdw_private. Please let me know if this
>> looks good to you. I am thinking of similar hook for CustomPath. I
>> will continue to add more path types to
>> reparameterize_path_by_child().
>>
>> I am wondering whether we should bring 0007 he patche adjusting code
>> to work with child-joins before 0006, partition-wise join. 0006 needs
>> it, but 0007 doesn't depend upon 0006. Will that be any better?
>>
>> [1] CAFjFpRcdrdsCRDbBu0J2pxwWbhb_sDWQUTVznBy_4XGr-p3+wA@mail.gmail.com,
>> subject "Asymmetry between parent and child wrt "false" quals"
>>
In an attempt to test the geqo side of this patch, I reduced
geqo_threshold to 6 and set enable_partitionwise_join to to true and
tried following query, which crashed,
explain select * from prt, prt2, prt3, prt32, prt4, prt42 where prt.a
= prt2.b and prt3.a = prt32.b and prt4.a = prt42.b and prt2.a > 1000
order by prt.a desc;
Stack-trace for the crash is as follows,
Program received signal SIGSEGV, Segmentation fault.
0x00000000007a43d1 in find_param_path_info (rel=0x2d3fe30,
required_outer=0x2ff6d30) at relnode.c:1534
1534 if (bms_equal(ppi->ppi_req_outer, required_outer))
(gdb) bt
#0 0x00000000007a43d1 in find_param_path_info (rel=0x2d3fe30,
required_outer=0x2ff6d30) at relnode.c:1534
#1 0x000000000079b8bb in reparameterize_path_by_child
(root=0x2df7550, path=0x2f6dec0, child_rel=0x2d4a860) at
pathnode.c:3455
#2 0x000000000075be30 in try_nestloop_path (root=0x2df7550,
joinrel=0x2ff51b0, outer_path=0x2f96540, inner_path=0x2f6dec0,
pathkeys=0x0,
jointype=JOIN_INNER, extra=0x7fffe6b4e130) at joinpath.c:344
#3 0x000000000075d55b in match_unsorted_outer (root=0x2df7550,
joinrel=0x2ff51b0, outerrel=0x2d4a860, innerrel=0x2d3fe30,
jointype=JOIN_INNER,
extra=0x7fffe6b4e130) at joinpath.c:1389
#4 0x000000000075bc5f in add_paths_to_joinrel (root=0x2df7550,
joinrel=0x2ff51b0, outerrel=0x2d4a860, innerrel=0x2d3fe30,
jointype=JOIN_INNER,
sjinfo=0x3076bc8, restrictlist=0x3077168) at joinpath.c:234
#5 0x000000000075f1d5 in populate_joinrel_with_paths (root=0x2df7550,
rel1=0x2d3fe30, rel2=0x2d4a860, joinrel=0x2ff51b0, sjinfo=0x3076bc8,
restrictlist=0x3077168) at joinrels.c:793
#6 0x0000000000760107 in try_partition_wise_join (root=0x2df7550,
rel1=0x2d3f6d8, rel2=0x2d4a1a0, joinrel=0x30752f0,
parent_sjinfo=0x7fffe6b4e2d0,
parent_restrictlist=0x3075768) at joinrels.c:1401
#7 0x000000000075f0e6 in make_join_rel (root=0x2df7550,
rel1=0x2d3f6d8, rel2=0x2d4a1a0) at joinrels.c:744
#8 0x0000000000742053 in merge_clump (root=0x2df7550,
clumps=0x3075270, new_clump=0x30752a8, force=0 '\000') at
geqo_eval.c:260
#9 0x0000000000741f1c in gimme_tree (root=0x2df7550, tour=0x2ff2430,
num_gene=6) at geqo_eval.c:199
#10 0x0000000000741df5 in geqo_eval (root=0x2df7550, tour=0x2ff2430,
num_gene=6) at geqo_eval.c:102
#11 0x000000000074288a in random_init_pool (root=0x2df7550,
pool=0x2ff23d0) at geqo_pool.c:109
#12 0x00000000007422a6 in geqo (root=0x2df7550, number_of_rels=6,
initial_rels=0x2ff22d0) at geqo_main.c:114
#13 0x0000000000747f19 in make_rel_from_joinlist (root=0x2df7550,
joinlist=0x2dce940) at allpaths.c:2333
#14 0x0000000000744e7e in make_one_rel (root=0x2df7550,
joinlist=0x2dce940) at allpaths.c:182
#15 0x0000000000772df9 in query_planner (root=0x2df7550,
tlist=0x2dec2c0, qp_callback=0x777ce1 <standard_qp_callback>,
qp_extra=0x7fffe6b4e700)
at planmain.c:254
Please let me know if any more information is required on this.
--
Regards,
Rafia Sabih
EnterpriseDB: http://www.enterprisedb.com/
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 277+ messages in thread
* Re: Partition-wise join for join between (declaratively) partitioned tables
2017-03-01 08:56 Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-09 01:14 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-10 10:43 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-13 19:24 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-14 12:04 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 00:33 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-15 12:49 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 19:00 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-16 10:48 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-16 15:05 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-17 10:28 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-17 13:15 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-18 00:10 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 13:44 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-20 16:28 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 16:52 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-20 16:56 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 17:19 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-20 18:03 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-21 11:46 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-21 17:10 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-22 08:17 ` Re: Partition-wise join for join between (declaratively) partitioned tables Rafia Sabih <[email protected]>
@ 2017-03-22 09:49 ` Ashutosh Bapat <[email protected]>
2017-03-22 12:01 ` Re: Partition-wise join for join between (declaratively) partitioned tables Rafia Sabih <[email protected]>
2017-03-22 12:46 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
0 siblings, 2 replies; 277+ messages in thread
From: Ashutosh Bapat @ 2017-03-22 09:49 UTC (permalink / raw)
To: Rafia Sabih <[email protected]>; +Cc: Robert Haas <[email protected]>; Rajkumar Raghuwanshi <[email protected]>; pgsql-hackers
>>>
> In an attempt to test the geqo side of this patch, I reduced
> geqo_threshold to 6 and set enable_partitionwise_join to to true and
> tried following query, which crashed,
>
> explain select * from prt, prt2, prt3, prt32, prt4, prt42 where prt.a
> = prt2.b and prt3.a = prt32.b and prt4.a = prt42.b and prt2.a > 1000
> order by prt.a desc;
>
> Stack-trace for the crash is as follows,
>
Nice catch. When reparameterize_path_by_child() may be running in a
temporary memory context while running in GEQO mode. It may add a new
PPI to base relation all in the temporary context. In the next GEQO
cycle, the ppilist will be clobbered since the temporary context is
reset for each geqo cycle. The fix is to allocate PPI in the same
memory context as the RelOptInfo similar to mark_dummy_rel().
I also found another problem. In geqo, we never call
generate_partition_wise_join_paths() which set cheapest paths for each
child-join. Because of this cheapest_*_paths are never set for those
rels, thus segfaulting in functions like sort_inner_and_outer() which
use those.
Here's patch fixing both the issues. Please let me know if it fixes
the issues you are seeing.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Attachments:
[application/octet-stream] geqo_fix.patch (2.6K, ../../CAFjFpRcPutbr4nVAsrY-5q=wCFrNK25_3MNhHgyYYM0yeOoj=Q@mail.gmail.com/2-geqo_fix.patch)
download | inline diff:
diff --git a/src/backend/optimizer/geqo/geqo_eval.c b/src/backend/optimizer/geqo/geqo_eval.c
index b5cab0c..e5883a2 100644
--- a/src/backend/optimizer/geqo/geqo_eval.c
+++ b/src/backend/optimizer/geqo/geqo_eval.c
@@ -267,6 +267,9 @@ merge_clump(PlannerInfo *root, List *clumps, Clump *new_clump, bool force)
/* Create GatherPaths for any useful partial paths for rel */
generate_gather_paths(root, joinrel);
+ /* Create "append" paths for partitioned joins. */
+ generate_partition_wise_join_paths(root, joinrel);
+
/* Find and save the cheapest paths for this joinrel */
set_cheapest(joinrel);
diff --git a/src/backend/optimizer/util/pathnode.c b/src/backend/optimizer/util/pathnode.c
index 64c4f6e..df7d452 100644
--- a/src/backend/optimizer/util/pathnode.c
+++ b/src/backend/optimizer/util/pathnode.c
@@ -31,6 +31,7 @@
#include "parser/parsetree.h"
#include "foreign/fdwapi.h"
#include "utils/lsyscache.h"
+#include "utils/memutils.h"
#include "utils/selfuncs.h"
@@ -3731,16 +3732,33 @@ reparameterize_path_by_child(PlannerInfo *root, Path *path,
/* If we already have a PPI for this parameterization, just return it */
new_ppi = find_param_path_info(new_path->parent, required_outer);
- /* If not build a new one and link it to the list of PPIs. */
+ /*
+ * If not build a new one and link it to the list of PPIs. When called
+ * during GEQO join planning, we are in a short-lived memory context. We
+ * must make sure that the new PPI and its contents attached to a baserel
+ * survives the GEQO cycle, else the baserel is trashed for future GEQO
+ * cycles. On the other hand, when we are adding new PPI to a joinrel
+ * during GEQO, we don't want that to clutter the main planning context.
+ * Upshot is that the best solution is to explicitly allocate new PPI in
+ * the same context the given RelOptInfo is in.
+ */
if (!new_ppi)
{
+ MemoryContext oldcontext;
+ RelOptInfo *rel = path->parent;
+
+ /* No, so choose correct context to make the dummy path in */
+ oldcontext = MemoryContextSwitchTo(GetMemoryChunkContext(rel));
+
new_ppi = makeNode(ParamPathInfo);
- new_ppi->ppi_req_outer = required_outer;
+ new_ppi->ppi_req_outer = bms_copy(required_outer);
new_ppi->ppi_rows = old_ppi->ppi_rows;
new_ppi->ppi_clauses = (List *) adjust_appendrel_attrs_multilevel(root,
(Node *) old_ppi->ppi_clauses,
child_rel);
- new_path->parent->ppilist = lappend(new_path->parent->ppilist, new_ppi);
+ new_path->parent->ppilist = lappend(rel->ppilist, new_ppi);
+
+ MemoryContextSwitchTo(oldcontext);
}
else
bms_free(required_outer);
^ permalink raw reply [nested|flat] 277+ messages in thread
* Re: Partition-wise join for join between (declaratively) partitioned tables
2017-03-01 08:56 Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-09 01:14 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-10 10:43 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-13 19:24 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-14 12:04 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 00:33 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-15 12:49 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 19:00 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-16 10:48 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-16 15:05 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-17 10:28 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-17 13:15 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-18 00:10 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 13:44 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-20 16:28 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 16:52 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-20 16:56 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 17:19 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-20 18:03 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-21 11:46 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-21 17:10 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-22 08:17 ` Re: Partition-wise join for join between (declaratively) partitioned tables Rafia Sabih <[email protected]>
2017-03-22 09:49 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
@ 2017-03-22 12:01 ` Rafia Sabih <[email protected]>
2017-03-22 12:47 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
1 sibling, 1 reply; 277+ messages in thread
From: Rafia Sabih @ 2017-03-22 12:01 UTC (permalink / raw)
To: Ashutosh Bapat <[email protected]>; +Cc: Robert Haas <[email protected]>; Rajkumar Raghuwanshi <[email protected]>; pgsql-hackers
On Wed, Mar 22, 2017 at 3:19 PM, Ashutosh Bapat
<[email protected]> wrote:
>>>>
>> In an attempt to test the geqo side of this patch, I reduced
>> geqo_threshold to 6 and set enable_partitionwise_join to to true and
>> tried following query, which crashed,
>>
>> explain select * from prt, prt2, prt3, prt32, prt4, prt42 where prt.a
>> = prt2.b and prt3.a = prt32.b and prt4.a = prt42.b and prt2.a > 1000
>> order by prt.a desc;
>>
>> Stack-trace for the crash is as follows,
>>
> Nice catch. When reparameterize_path_by_child() may be running in a
> temporary memory context while running in GEQO mode. It may add a new
> PPI to base relation all in the temporary context. In the next GEQO
> cycle, the ppilist will be clobbered since the temporary context is
> reset for each geqo cycle. The fix is to allocate PPI in the same
> memory context as the RelOptInfo similar to mark_dummy_rel().
>
> I also found another problem. In geqo, we never call
> generate_partition_wise_join_paths() which set cheapest paths for each
> child-join. Because of this cheapest_*_paths are never set for those
> rels, thus segfaulting in functions like sort_inner_and_outer() which
> use those.
>
> Here's patch fixing both the issues. Please let me know if it fixes
> the issues you are seeing.
I tested the applied patch, it is fixing the reported issue.
--
Regards,
Rafia Sabih
EnterpriseDB: http://www.enterprisedb.com/
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 277+ messages in thread
* Re: Partition-wise join for join between (declaratively) partitioned tables
2017-03-01 08:56 Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-09 01:14 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-10 10:43 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-13 19:24 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-14 12:04 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 00:33 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-15 12:49 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 19:00 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-16 10:48 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-16 15:05 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-17 10:28 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-17 13:15 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-18 00:10 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 13:44 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-20 16:28 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 16:52 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-20 16:56 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 17:19 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-20 18:03 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-21 11:46 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-21 17:10 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-22 08:17 ` Re: Partition-wise join for join between (declaratively) partitioned tables Rafia Sabih <[email protected]>
2017-03-22 09:49 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-22 12:01 ` Re: Partition-wise join for join between (declaratively) partitioned tables Rafia Sabih <[email protected]>
@ 2017-03-22 12:47 ` Ashutosh Bapat <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Ashutosh Bapat @ 2017-03-22 12:47 UTC (permalink / raw)
To: Rafia Sabih <[email protected]>; +Cc: Robert Haas <[email protected]>; Rajkumar Raghuwanshi <[email protected]>; pgsql-hackers
>
> I tested the applied patch, it is fixing the reported issue.
Thanks for the confirmation Rafia. I have included the fix in the
latest set of patches.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 277+ messages in thread
* Re: Partition-wise join for join between (declaratively) partitioned tables
2017-03-01 08:56 Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-09 01:14 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-10 10:43 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-13 19:24 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-14 12:04 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 00:33 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-15 12:49 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 19:00 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-16 10:48 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-16 15:05 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-17 10:28 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-17 13:15 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-18 00:10 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 13:44 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-20 16:28 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 16:52 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-20 16:56 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 17:19 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-20 18:03 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-21 11:46 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-21 17:10 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-22 08:17 ` Re: Partition-wise join for join between (declaratively) partitioned tables Rafia Sabih <[email protected]>
2017-03-22 09:49 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
@ 2017-03-22 12:46 ` Ashutosh Bapat <[email protected]>
2017-03-22 13:02 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-22 19:47 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
1 sibling, 2 replies; 277+ messages in thread
From: Ashutosh Bapat @ 2017-03-22 12:46 UTC (permalink / raw)
To: Rafia Sabih <[email protected]>; +Cc: Robert Haas <[email protected]>; Rajkumar Raghuwanshi <[email protected]>; pgsql-hackers
Here's set of updated patches rebased on
1148e22a82edc96172fc78855da392b6f0015c88.
I have fixed all the issues reported till now.
I have also completed reparameterize_path_by_child() for all the
required paths. There's no TODO there now. :) The function has grown
quite long now and might take some time to review. Given the size, I
am wondering whether we should separate that fix from the main
partition-wise join fix. That will make reviewing that function
easier, allowing a careful review. Here's the idea how that can be
done. As explained in the commit of 0009, the function is required in
case of lateral joins between partitioned relations. For a A LATERAL
JOIN B, B is the minimum required parameterization by A. Hence
children of A i.e. A1, A2 ... all require their paths to be
parameterized by B. When that comes to partition-wise joins, A1
requires its paths to be parameterized by B1 (matching partition from
B). Otherwise we can not create paths for A1B1. This means that we
require to reparameterize all A1's paths to be reparameterized by B1
using function reparameterize_paths_by_child(). So the function needs
to support reparameterization of all the paths; we do not know which
of those have survived add_path(). But if we disable partition-wise
join for lateral joins i.e. when direct_lateral_relids of one relation
contains the any subset of the relids in the other relation, we do not
need reparameterize_path_by_child(). Please let me know if this
strategy will help to make review and commit easier.
After the commit,
commit d3cc37f1d801a6b5cad9bf179274a8d767f1ee50
Author: Robert Haas <[email protected]>
Date: Tue Mar 21 09:48:04 2017 -0400
Don't scan partitioned tables.
We do not create any AppendRelInfos and hence RelOptInfos for the
partitioned tables. My approach to attach multi-level partitioned join
was to store RelOptInfos of immediate partitions in part_rels of
RelOptInfo of a partitioned table, thus maintaining a tree of
RelOptInfos reflecting partitioning tree. This allows to add append
paths to intermediate RelOptInfos, flattening them as we go up the
partitioning hierarchy. With no RelOptInfos for intermediate
partitions, we can support multi-level partition-wise join only in
limited cases when the partitioning hierarchy of the joining table
exactly matches. Please refer [1] for some more discussion.
I think we need the RelOptInfos for the partitions, which are
partitioned to hold the "append" paths containing paths from their
children and to match the partitions in partition-wise join. Similar
hierarchy will be created for partitioned joins, with partitioned join
partitions. So, I have not changed the multi-level partition-wise join
support patches. After applying 0011-0013 the multi-level partitioning
tests fail with error "could not find the RelOptInfo of a partition
with oid", since it does not find the RelOptInfos of partitions which
are partitioned.
[1] https://www.postgresql.org/message-id/CAFjFpRceMmx26653XFAYvc5KVQcrzcKScVFqZdbXV%[email protected]...
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Attachments:
[application/zip] pg_dp_join_patches_v12.zip (60.7K, ../../CAFjFpRefs5ZMnxQ2vP9v5zOtWtNPuiMYc01sb1SWjCOB1CT=uQ@mail.gmail.com/2-pg_dp_join_patches_v12.zip)
download
^ permalink raw reply [nested|flat] 277+ messages in thread
* Re: Partition-wise join for join between (declaratively) partitioned tables
2017-03-01 08:56 Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-09 01:14 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-10 10:43 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-13 19:24 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-14 12:04 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 00:33 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-15 12:49 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 19:00 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-16 10:48 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-16 15:05 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-17 10:28 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-17 13:15 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-18 00:10 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 13:44 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-20 16:28 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 16:52 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-20 16:56 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 17:19 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-20 18:03 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-21 11:46 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-21 17:10 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-22 08:17 ` Re: Partition-wise join for join between (declaratively) partitioned tables Rafia Sabih <[email protected]>
2017-03-22 09:49 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-22 12:46 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
@ 2017-03-22 13:02 ` Robert Haas <[email protected]>
2017-03-22 13:59 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
1 sibling, 1 reply; 277+ messages in thread
From: Robert Haas @ 2017-03-22 13:02 UTC (permalink / raw)
To: Ashutosh Bapat <[email protected]>; +Cc: Rafia Sabih <[email protected]>; Rajkumar Raghuwanshi <[email protected]>; pgsql-hackers
On Wed, Mar 22, 2017 at 8:46 AM, Ashutosh Bapat
<[email protected]> wrote:
> I have also completed reparameterize_path_by_child() for all the
> required paths. There's no TODO there now. :) The function has grown
> quite long now and might take some time to review. Given the size, I
> am wondering whether we should separate that fix from the main
> partition-wise join fix. That will make reviewing that function
> easier, allowing a careful review. Here's the idea how that can be
> done. As explained in the commit of 0009, the function is required in
> case of lateral joins between partitioned relations. For a A LATERAL
> JOIN B, B is the minimum required parameterization by A. Hence
> children of A i.e. A1, A2 ... all require their paths to be
> parameterized by B. When that comes to partition-wise joins, A1
> requires its paths to be parameterized by B1 (matching partition from
> B). Otherwise we can not create paths for A1B1. This means that we
> require to reparameterize all A1's paths to be reparameterized by B1
> using function reparameterize_paths_by_child(). So the function needs
> to support reparameterization of all the paths; we do not know which
> of those have survived add_path(). But if we disable partition-wise
> join for lateral joins i.e. when direct_lateral_relids of one relation
> contains the any subset of the relids in the other relation, we do not
> need reparameterize_path_by_child(). Please let me know if this
> strategy will help to make review and commit easier.
In my testing last week, reparameterize_path_by_child() was essential
for nested loops to work properly, even without LATERAL. Without it,
the parameterized path ends up containing vars that reference the
parent varno instead of the child varno. That confused later planner
stages so that those Vars did not get replaced with Param during
replace_nestloop_params(), eventually resulting in a crash at
execution time. Based on that experiment, I think we could consider
having reparameterize_path_by_child() handle only scan paths as
reparameterize_path() does, and just give up on plans like this:
Append
-> Left Join
-> Scan on a
-> Inner Join
-> Index Scan on b
-> Index Scan on c
[repeat for each partition]
But I doubt we can get by without it altogether.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 277+ messages in thread
* Re: Partition-wise join for join between (declaratively) partitioned tables
2017-03-01 08:56 Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-09 01:14 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-10 10:43 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-13 19:24 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-14 12:04 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 00:33 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-15 12:49 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 19:00 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-16 10:48 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-16 15:05 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-17 10:28 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-17 13:15 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-18 00:10 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 13:44 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-20 16:28 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 16:52 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-20 16:56 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 17:19 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-20 18:03 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-21 11:46 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-21 17:10 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-22 08:17 ` Re: Partition-wise join for join between (declaratively) partitioned tables Rafia Sabih <[email protected]>
2017-03-22 09:49 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-22 12:46 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-22 13:02 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
@ 2017-03-22 13:59 ` Ashutosh Bapat <[email protected]>
2017-03-22 17:16 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
0 siblings, 1 reply; 277+ messages in thread
From: Ashutosh Bapat @ 2017-03-22 13:59 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: Rafia Sabih <[email protected]>; Rajkumar Raghuwanshi <[email protected]>; pgsql-hackers
On Wed, Mar 22, 2017 at 6:32 PM, Robert Haas <[email protected]> wrote:
> On Wed, Mar 22, 2017 at 8:46 AM, Ashutosh Bapat
> <[email protected]> wrote:
>> I have also completed reparameterize_path_by_child() for all the
>> required paths. There's no TODO there now. :) The function has grown
>> quite long now and might take some time to review. Given the size, I
>> am wondering whether we should separate that fix from the main
>> partition-wise join fix. That will make reviewing that function
>> easier, allowing a careful review. Here's the idea how that can be
>> done. As explained in the commit of 0009, the function is required in
>> case of lateral joins between partitioned relations. For a A LATERAL
>> JOIN B, B is the minimum required parameterization by A. Hence
>> children of A i.e. A1, A2 ... all require their paths to be
>> parameterized by B. When that comes to partition-wise joins, A1
>> requires its paths to be parameterized by B1 (matching partition from
>> B). Otherwise we can not create paths for A1B1. This means that we
>> require to reparameterize all A1's paths to be reparameterized by B1
>> using function reparameterize_paths_by_child(). So the function needs
>> to support reparameterization of all the paths; we do not know which
>> of those have survived add_path(). But if we disable partition-wise
>> join for lateral joins i.e. when direct_lateral_relids of one relation
>> contains the any subset of the relids in the other relation, we do not
>> need reparameterize_path_by_child(). Please let me know if this
>> strategy will help to make review and commit easier.
>
> In my testing last week, reparameterize_path_by_child() was essential
> for nested loops to work properly, even without LATERAL. Without it,
> the parameterized path ends up containing vars that reference the
> parent varno instead of the child varno. That confused later planner
> stages so that those Vars did not get replaced with Param during
> replace_nestloop_params(), eventually resulting in a crash at
> execution time.
I half-described the solution. Sorry. Along-with disabling
partition-wise lateral joins, we have to disable nested loop
child-joins where inner child is parameterized by the parent of the
outer one. We will still have nestloop join between parents where
inner relation is parameterized by the outer and every child of inner
is parameterized by the outer. But we won't create nest loop joins
where inner child is parameterized by the outer child, where we
require reparameterize_path_by_child. We will loose this optimization
only till we get reparameterize_path_by_child() committed. Basically,
in try_nestloop_path() (in the patch 0009), if
(PATH_PARAM_BY_PARENT(inner_path, outer_path->parent)), give up
creating nest loop path. That shouldn't create any problems.
Did you experiment with this change in try_nestloop_path()? Can you
please share the testcase? I will take a look at it.
> Based on that experiment, I think we could consider
> having reparameterize_path_by_child() handle only scan paths as
> reparameterize_path() does, and just give up on plans like this:
>
> Append
> -> Left Join
> -> Scan on a
> -> Inner Join
> -> Index Scan on b
> -> Index Scan on c
> [repeat for each partition]
>
I am assuming that a, b and c are partitions of A, B and C resp. which
are being joined and both or one of the scans on b and c are
parameteried by a or scan of c is parameterized by b.
I don't think we will get away by supporting just scan paths, since
the inner side of lateral join can be any paths not just scan path. Or
you are suggesting that we disable partition-wise lateral join and
support reparameterization of only scan paths?
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 277+ messages in thread
* Re: Partition-wise join for join between (declaratively) partitioned tables
2017-03-01 08:56 Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-09 01:14 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-10 10:43 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-13 19:24 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-14 12:04 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 00:33 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-15 12:49 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 19:00 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-16 10:48 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-16 15:05 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-17 10:28 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-17 13:15 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-18 00:10 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 13:44 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-20 16:28 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 16:52 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-20 16:56 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 17:19 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-20 18:03 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-21 11:46 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-21 17:10 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-22 08:17 ` Re: Partition-wise join for join between (declaratively) partitioned tables Rafia Sabih <[email protected]>
2017-03-22 09:49 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-22 12:46 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-22 13:02 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-22 13:59 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
@ 2017-03-22 17:16 ` Robert Haas <[email protected]>
2017-03-23 04:22 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
0 siblings, 1 reply; 277+ messages in thread
From: Robert Haas @ 2017-03-22 17:16 UTC (permalink / raw)
To: Ashutosh Bapat <[email protected]>; +Cc: Rafia Sabih <[email protected]>; Rajkumar Raghuwanshi <[email protected]>; pgsql-hackers
On Wed, Mar 22, 2017 at 9:59 AM, Ashutosh Bapat
<[email protected]> wrote:
>> In my testing last week, reparameterize_path_by_child() was essential
>> for nested loops to work properly, even without LATERAL. Without it,
>> the parameterized path ends up containing vars that reference the
>> parent varno instead of the child varno. That confused later planner
>> stages so that those Vars did not get replaced with Param during
>> replace_nestloop_params(), eventually resulting in a crash at
>> execution time.
>
> I half-described the solution. Sorry. Along-with disabling
> partition-wise lateral joins, we have to disable nested loop
> child-joins where inner child is parameterized by the parent of the
> outer one. We will still have nestloop join between parents where
> inner relation is parameterized by the outer and every child of inner
> is parameterized by the outer. But we won't create nest loop joins
> where inner child is parameterized by the outer child, where we
> require reparameterize_path_by_child. We will loose this optimization
> only till we get reparameterize_path_by_child() committed. Basically,
> in try_nestloop_path() (in the patch 0009), if
> (PATH_PARAM_BY_PARENT(inner_path, outer_path->parent)), give up
> creating nest loop path. That shouldn't create any problems.
>
> Did you experiment with this change in try_nestloop_path()? Can you
> please share the testcase? I will take a look at it.
I didn't save the test case. It was basically just forcing a
partitionwise nestloop join between two equipartitioned tables, with
the calls to adjust_appendrel_attrs() ripped out of
reparameterize_path_by_child(), just to see what would break.
>> Based on that experiment, I think we could consider
>> having reparameterize_path_by_child() handle only scan paths as
>> reparameterize_path() does, and just give up on plans like this:
>>
>> Append
>> -> Left Join
>> -> Scan on a
>> -> Inner Join
>> -> Index Scan on b
>> -> Index Scan on c
>> [repeat for each partition]
>>
>
> I am assuming that a, b and c are partitions of A, B and C resp. which
> are being joined and both or one of the scans on b and c are
> parameteried by a or scan of c is parameterized by b.
Yes.
> I don't think we will get away by supporting just scan paths, since
> the inner side of lateral join can be any paths not just scan path. Or
> you are suggesting that we disable partition-wise lateral join and
> support reparameterization of only scan paths?
I think if you can do a straight-up partitionwise nested loop between
two tables A and B, that's pretty bad. But if there are more complex
cases that involve parameterizing entire join trees which aren't
covered, that's less bad. Parallel query almost entirely punts on
LATERAL right now, and nobody's complained yet. I'm sure that'll need
to get fixed someday, but not today.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 277+ messages in thread
* Re: Partition-wise join for join between (declaratively) partitioned tables
2017-03-01 08:56 Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-09 01:14 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-10 10:43 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-13 19:24 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-14 12:04 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 00:33 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-15 12:49 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 19:00 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-16 10:48 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-16 15:05 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-17 10:28 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-17 13:15 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-18 00:10 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 13:44 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-20 16:28 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 16:52 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-20 16:56 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 17:19 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-20 18:03 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-21 11:46 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-21 17:10 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-22 08:17 ` Re: Partition-wise join for join between (declaratively) partitioned tables Rafia Sabih <[email protected]>
2017-03-22 09:49 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-22 12:46 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-22 13:02 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-22 13:59 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-22 17:16 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
@ 2017-03-23 04:22 ` Ashutosh Bapat <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Ashutosh Bapat @ 2017-03-23 04:22 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: Rafia Sabih <[email protected]>; Rajkumar Raghuwanshi <[email protected]>; pgsql-hackers
>
>> I don't think we will get away by supporting just scan paths, since
>> the inner side of lateral join can be any paths not just scan path. Or
>> you are suggesting that we disable partition-wise lateral join and
>> support reparameterization of only scan paths?
>
> I think if you can do a straight-up partitionwise nested loop between
> two tables A and B, that's pretty bad.
Ok.
> But if there are more complex
> cases that involve parameterizing entire join trees which aren't
> covered, that's less bad. Parallel query almost entirely punts on
> LATERAL right now, and nobody's complained yet. I'm sure that'll need
> to get fixed someday, but not today.
>
Ok.
I am suggesting this possibility in case we run of time to review and
commit reparameterize_path_by_child() entirely. If we can do that, I
will be happy.
In case, we have to include a stripped down version of
reparameterize_path_by_child(), with which I am fine too, we will need
to disable LATERAL joins, so that we don't end up with an error "could
not devise a query plan for the given query".
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 277+ messages in thread
* Re: Partition-wise join for join between (declaratively) partitioned tables
2017-03-01 08:56 Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-09 01:14 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-10 10:43 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-13 19:24 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-14 12:04 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 00:33 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-15 12:49 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 19:00 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-16 10:48 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-16 15:05 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-17 10:28 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-17 13:15 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-18 00:10 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 13:44 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-20 16:28 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 16:52 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-20 16:56 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 17:19 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-20 18:03 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-21 11:46 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-21 17:10 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-22 08:17 ` Re: Partition-wise join for join between (declaratively) partitioned tables Rafia Sabih <[email protected]>
2017-03-22 09:49 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-22 12:46 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
@ 2017-03-22 19:47 ` Robert Haas <[email protected]>
2017-03-23 12:48 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
1 sibling, 1 reply; 277+ messages in thread
From: Robert Haas @ 2017-03-22 19:47 UTC (permalink / raw)
To: Ashutosh Bapat <[email protected]>; +Cc: Rafia Sabih <[email protected]>; Rajkumar Raghuwanshi <[email protected]>; pgsql-hackers
On Wed, Mar 22, 2017 at 8:46 AM, Ashutosh Bapat
<[email protected]> wrote:
> Here's set of updated patches rebased on
> 1148e22a82edc96172fc78855da392b6f0015c88.
>
> I have fixed all the issues reported till now.
I don't understand why patch 0001 ends up changing every existing test
for RELOPT_JOINREL anywhere in the source tree to use IS_JOIN_REL(),
yet none of the existing tests for RELOPT_OTHER_MEMBER_REL end up
getting changed to use IS_OTHER_REL(). That's very surprising. Some
of those tests are essentially checking for something that is going to
have a scan plan rather than a join or upper plan, and those tests
probably don't need to be modified; for example, the test in
set_rel_consider_parallel() is obviously of this type. But others are
testing whether we've got some kind of child rel, and those seem like
they might need work. Going through a few specific examples:
- generate_join_implied_equalities_for_ecs() assumes that any child
rel is an other member rel.
- generate_join_implied_equalities_broken() assumes that any child rel
is an other member rel.
- generate_implied_equalities_for_column() set is_child_rel on the
assumption that only an other member rel can be a child rel.
- eclass_useful_for_merging() assumes that the only kind of child rel
is an other member rel.
- find_childrel_appendrelinfo() assumes that any child rel is an other
member rel.
- find_childrel_top_parent() and find_childrel_parents() assume that
children must be other member rels and their parents must be baserels.
- adjust_appendrel_attrs_multilevel() assumes that children must be
other member rels and their parents must be baserels.
It's possible that, for various reasons, none of these code paths
would ever be reachable by a child join, but it doesn't look likely to
me. And even if that's true, some comment updates are probably
needed, and maybe some renaming of functions too.
In postgres_fdw, get_useful_ecs_for_relation() assumes that any child
rel is an other member rel. I'm not sure if we're hoping that
partitionwise join will work with postgres_fdw's join pushdown out of
the chute, but clearly this would need to be adjusted to have any
chance of being right.
Some that seem OK:
- set_rel_consider_parallel() is fine.
- set_append_rel_size() is only going to be called for baserels or
their children, so it's fine.
- relation_excluded_by_constraints() is only intended to be called on
baserels or their children, so it's fine.
- check_index_predicates() is only intended to be called on baserels
or their children, so it's fine.
- query_planner() loops over baserels and their children, so it's fine.
Perhaps we could introduce an IS_BASEREL_OR_CHILD() test that could be
used in some of these places, just for symmetry. The point is that
there are really three questions here: (1) is it some kind of baserel
(parent or child)? (2) is it some kind of joinrel (parent or child)?
and (3) is it some kind of child (baserel or join)? Right now, both
#2 and #3 are tested by just comparing against
RELOPT_OTHER_MEMBER_REL, but they become different tests as soon as we
add child joinrels. The goal of 0001, IMV, ought to be to try to
figure out which of #1, #2, and #3 is being checked in each case and
make that clear via use of an appropriate macro. (If is-other-baserel
is the real test, then fine, but I bet that's a rare case.)
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 277+ messages in thread
* Re: Partition-wise join for join between (declaratively) partitioned tables
2017-03-01 08:56 Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-09 01:14 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-10 10:43 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-13 19:24 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-14 12:04 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 00:33 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-15 12:49 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-15 19:00 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-16 10:48 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-16 15:05 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-17 10:28 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-17 13:15 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-18 00:10 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 13:44 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-20 16:28 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 16:52 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-20 16:56 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-20 17:19 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-20 18:03 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
2017-03-21 11:46 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-21 17:10 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-22 08:17 ` Re: Partition-wise join for join between (declaratively) partitioned tables Rafia Sabih <[email protected]>
2017-03-22 09:49 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-22 12:46 ` Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-22 19:47 ` Re: Partition-wise join for join between (declaratively) partitioned tables Robert Haas <[email protected]>
@ 2017-03-23 12:48 ` Ashutosh Bapat <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Ashutosh Bapat @ 2017-03-23 12:48 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: Rafia Sabih <[email protected]>; Rajkumar Raghuwanshi <[email protected]>; pgsql-hackers
On Thu, Mar 23, 2017 at 1:17 AM, Robert Haas <[email protected]> wrote:
> On Wed, Mar 22, 2017 at 8:46 AM, Ashutosh Bapat
> <[email protected]> wrote:
>> Here's set of updated patches rebased on
>> 1148e22a82edc96172fc78855da392b6f0015c88.
>>
>> I have fixed all the issues reported till now.
>
> I don't understand why patch 0001 ends up changing every existing test
> for RELOPT_JOINREL anywhere in the source tree to use IS_JOIN_REL(),
> yet none of the existing tests for RELOPT_OTHER_MEMBER_REL end up
> getting changed to use IS_OTHER_REL(). That's very surprising. Some
> of those tests are essentially checking for something that is going to
> have a scan plan rather than a join or upper plan, and those tests
> probably don't need to be modified; for example, the test in
> set_rel_consider_parallel() is obviously of this type. But others are
> testing whether we've got some kind of child rel, and those seem like
> they might need work. Going through a few specific examples:
>
> - generate_join_implied_equalities_for_ecs() assumes that any child
> rel is an other member rel.
> - generate_join_implied_equalities_broken() assumes that any child rel
> is an other member rel.
Fixed those.
> - generate_implied_equalities_for_column() set is_child_rel on the
> assumption that only an other member rel can be a child rel.
This function is called for indexes, which are not defined on the
join relations. So, we shouldn't worry about child-joins here. I have
added an assertion in there to make sure that that function gets
called only for base and "other" member rels.
> - eclass_useful_for_merging() assumes that the only kind of child rel
> is an other member rel.
This was being fixed in a later patch which had many small fixes for
handling child-joins. But now I have moved that fix into 0001.
> - find_childrel_appendrelinfo() assumes that any child rel is an other
> member rel.
The function is called for "other" member relation only. For joins we
use find_appinfos_by_relids() We could replace
find_childrel_appendrelinfo() with find_appinfos_by_relids(), which
does same thing as find_childrel_appendrelinfo() for a relids set. But
find_appinfos_by_relids() returns a list of AppendRelInfos, hence
using it instead of find_childrel_appendrelinfo() will spend some
memory and CPU cycles in creating a one element list and then
extracting that element out of the list. So, I have not replaced
usages of find_childrel_appendrelinfo() with
find_appinfos_by_relids(). This also simplifies changes to
get_useful_ecs_for_relation().
> - find_childrel_top_parent() and find_childrel_parents() assume that
> children must be other member rels and their parents must be baserels.
For partition-wise join implementation we save relids of topmost
parent in RelOptInfo of child. We can directly use that instead of
calling find_childrel_top_parent(). So, in 0001 I am adding
top_parent_relids in RelOptInfo and getting rid of
find_childrel_top_parent(). This also fixes
get_useful_ecs_for_relation() in a better way. find_childrel_parents()
is called only for simple relations not joins, since it's callers are
called only for simple relations. I have added an assertion to that
effect.
> - adjust_appendrel_attrs_multilevel() assumes that children must be
> other member rels and their parents must be baserels.
It was being fixed in a later patch. In the attached patch set 0001
changes it to use IS_OTHER_REL().
>
> It's possible that, for various reasons, none of these code paths
> would ever be reachable by a child join, but it doesn't look likely to
> me. And even if that's true, some comment updates are probably
> needed, and maybe some renaming of functions too.
Now commit messages of 0001 explains which instances of
RELOPT_OTHER_MEMBER_REL and RELOPT_BASEREL have been changed, and
which have been retained and why. Also, added assertions wherever
necessary.
>
> In postgres_fdw, get_useful_ecs_for_relation() assumes that any child
> rel is an other member rel. I'm not sure if we're hoping that
> partitionwise join will work with postgres_fdw's join pushdown out of
> the chute, but clearly this would need to be adjusted to have any
> chance of being right.
Fixed this as explained above.
>
> Some that seem OK:
>
> - set_rel_consider_parallel() is fine.
> - set_append_rel_size() is only going to be called for baserels or
> their children, so it's fine.
> - relation_excluded_by_constraints() is only intended to be called on
> baserels or their children, so it's fine.
> - check_index_predicates() is only intended to be called on baserels
> or their children, so it's fine.
> - query_planner() loops over baserels and their children, so it's fine.
>
Right.
> Perhaps we could introduce an IS_BASEREL_OR_CHILD() test that could be
> used in some of these places, just for symmetry.
I was wondering about this as well. Although, I though it better not
to touch base relations in partition-wise join. But now, I have added
that macro and adjusted corresponding tests in the code. See 0001.
You may actually want to squash 0001 and 0002 into a single patch. But
for now, I have left those as separate.
> The point is that
> there are really three questions here: (1) is it some kind of baserel
> (parent or child)? (2) is it some kind of joinrel (parent or child)?
> and (3) is it some kind of child (baserel or join)? Right now, both
> #2 and #3 are tested by just comparing against
> RELOPT_OTHER_MEMBER_REL, but they become different tests as soon as we
> add child joinrels. The goal of 0001, IMV, ought to be to try to
> figure out which of #1, #2, and #3 is being checked in each case and
> make that clear via use of an appropriate macro. (If is-other-baserel
> is the real test, then fine, but I bet that's a rare case.)
Agreed. I have gone through all the cases, and fixed the necessary
ones as explained above and in the commit messages of 0001.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Attachments:
[application/zip] pg_dp_join_patches_v13.zip (65.3K, ../../CAFjFpRcMWwepj-Do1otxQ-GApGPSZ1FmH7YQvQTwzQOGczq_sw@mail.gmail.com/2-pg_dp_join_patches_v13.zip)
download
^ permalink raw reply [nested|flat] 277+ messages in thread
* Question on compatibility of Postgres with Open JDK
@ 2019-01-30 06:28 Pratheej Chandrika <[email protected]>
2019-01-30 06:33 ` Re: [BDR] Question on compatibility of Postgres with Open JDK Craig Ringer <[email protected]>
0 siblings, 1 reply; 277+ messages in thread
From: Pratheej Chandrika @ 2019-01-30 06:28 UTC (permalink / raw)
To: [email protected]; pgsql-hackers
Hello,
We are using Postgresql (postgresql-bdr94).
Please let us know whether Postgresql supports Open JDK?
Thanks
Pratheej
^ permalink raw reply [nested|flat] 277+ messages in thread
* Re: [BDR] Question on compatibility of Postgres with Open JDK
2019-01-30 06:28 Question on compatibility of Postgres with Open JDK Pratheej Chandrika <[email protected]>
@ 2019-01-30 06:33 ` Craig Ringer <[email protected]>
2019-01-30 07:28 ` Re: [BDR] Question on compatibility of Postgres with Open JDK Pratheej Chandrika <[email protected]>
0 siblings, 1 reply; 277+ messages in thread
From: Craig Ringer @ 2019-01-30 06:33 UTC (permalink / raw)
To: Pratheej Chandrika <[email protected]>; +Cc: Postgres-BDR and pglogical Mailing List <[email protected]>; pgsql-hackers
I don't understand the question.
If you want to use PgJDBC, then yes, PgJDBC works on OpenJDK. You do not
need to use pgjdbc 9.4 with PostgreSQL 9.4, you may use the latest version.
If you want to use pl/java, then I don't know if it's been tested with
postgres-bdr 9.4. But it should work fine if it works with normal community
postgres 9.4.
On Wed, 30 Jan 2019 at 14:28, Pratheej Chandrika <
[email protected]> wrote:
> Hello,
> We are using Postgresql (postgresql-bdr94).
>
> Please let us know whether Postgresql supports Open JDK?
>
> Thanks
> Pratheej
>
> --
> You received this message because you are subscribed to the Google Groups
> "Postgres-BDR and pglogical Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> Visit this group at
> https://groups.google.com/a/2ndquadrant.com/group/bdr-list/.
> To view this discussion on the web visit
> https://groups.google.com/a/2ndquadrant.com/d/msgid/bdr-list/CA%2BOir%3DMAc9OU4iNm%3DRBr%2BF2fLOSjJT...
> <https://groups.google.com/a/2ndquadrant.com/d/msgid/bdr-list/CA%2BOir%3DMAc9OU4iNm%3DRBr%2BF2fLOSjJT...;
> .
>
--
Craig Ringer http://www.2ndQuadrant.com/
2ndQuadrant - PostgreSQL Solutions for the Enterprise
^ permalink raw reply [nested|flat] 277+ messages in thread
* Re: [BDR] Question on compatibility of Postgres with Open JDK
2019-01-30 06:28 Question on compatibility of Postgres with Open JDK Pratheej Chandrika <[email protected]>
2019-01-30 06:33 ` Re: [BDR] Question on compatibility of Postgres with Open JDK Craig Ringer <[email protected]>
@ 2019-01-30 07:28 ` Pratheej Chandrika <[email protected]>
2019-01-30 08:27 ` Re: [BDR] Question on compatibility of Postgres with Open JDK Craig Ringer <[email protected]>
0 siblings, 1 reply; 277+ messages in thread
From: Pratheej Chandrika @ 2019-01-30 07:28 UTC (permalink / raw)
To: Craig Ringer <[email protected]>; +Cc: Postgres-BDR and pglogical Mailing List <[email protected]>; pgsql-hackers
--00000000000040e9470580a7da42
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Criag,
Thanks a lot for the prompt reply.
^ permalink raw reply [nested|flat] 277+ messages in thread
* Re: [BDR] Question on compatibility of Postgres with Open JDK
2019-01-30 06:28 Question on compatibility of Postgres with Open JDK Pratheej Chandrika <[email protected]>
2019-01-30 06:33 ` Re: [BDR] Question on compatibility of Postgres with Open JDK Craig Ringer <[email protected]>
2019-01-30 07:28 ` Re: [BDR] Question on compatibility of Postgres with Open JDK Pratheej Chandrika <[email protected]>
@ 2019-01-30 08:27 ` Craig Ringer <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Craig Ringer @ 2019-01-30 08:27 UTC (permalink / raw)
To: Pratheej Chandrika <[email protected]>; +Cc: Postgres-BDR and pglogical Mailing List <[email protected]>; pgsql-hackers
On Wed, 30 Jan 2019 at 15:28, Pratheej Chandrika <
[email protected]> wrote:
> Criag,
> Thanks a lot for the prompt reply.
>
> From what you mentioned, I assume that other the client side jdbc there
> is no Java dependency from Server side. What I mean is I assume there is no
> jdk/java dependency for Postgres server to work. Request your input.
>
Correct.
Please see the PostgreSQL and PgJDBC manuals for more details.
--
Craig Ringer http://www.2ndQuadrant.com/
2ndQuadrant - PostgreSQL Solutions for the Enterprise
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v56 6/6] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar_16_10_27_55_2021_500)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v44 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index 2b2761a588..eaf4448943 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Mon_Dec_21_17_16_20_2020_608)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v50 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_18_29_34_2021_806)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v45 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Jan__8_10_24_34_2021_185)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v50 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_18_29_34_2021_806)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v50 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_18_29_34_2021_806)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v47 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_21_12_03_48_2021_284)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v56 6/6] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar_16_10_27_55_2021_500)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v48 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Mar__5_17_18_56_2021_497)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v49 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_16_53_11_2021_575)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v52 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_17_51_37_2021_192)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v51 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_12_10_39_2021_432)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v46 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_14_15_14_25_2021_903)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v48 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Mar__5_17_18_56_2021_497)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v51 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_12_10_39_2021_432)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v45 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Jan__8_10_24_34_2021_185)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v45 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Jan__8_10_24_34_2021_185)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v50 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_18_29_34_2021_806)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v47 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_21_12_03_48_2021_284)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v48 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Mar__5_17_18_56_2021_497)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v48 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Mar__5_17_18_56_2021_497)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v47 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_21_12_03_48_2021_284)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v49 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_16_53_11_2021_575)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v51 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_12_10_39_2021_432)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v51 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_12_10_39_2021_432)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v52 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_17_51_37_2021_192)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v48 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Mar__5_17_18_56_2021_497)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v57 6/6] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index 84b22f4ac9..a2c88bd3a4 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Mar_18_16_56_02_2021_947)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v46 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_14_15_14_25_2021_903)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v47 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_21_12_03_48_2021_284)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v46 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_14_15_14_25_2021_903)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v51 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_12_10_39_2021_432)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v49 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_16_53_11_2021_575)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v46 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_14_15_14_25_2021_903)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v49 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_16_53_11_2021_575)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v52 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_17_51_37_2021_192)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v51 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_12_10_39_2021_432)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v48 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Mar__5_17_18_56_2021_497)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v56 6/6] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar_16_10_27_55_2021_500)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v46 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_14_15_14_25_2021_903)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v51 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_12_10_39_2021_432)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v49 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_16_53_11_2021_575)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v45 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Jan__8_10_24_34_2021_185)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v56 6/6] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar_16_10_27_55_2021_500)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v48 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Mar__5_17_18_56_2021_497)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v41 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index 25eabbb1ad..dd35920e82 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.18.4
----Next_Part(Fri_Nov__6_09_27_56_2020_738)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v56 6/6] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar_16_10_27_55_2021_500)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v50 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_18_29_34_2021_806)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v51 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_12_10_39_2021_432)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v56 6/6] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar_16_10_27_55_2021_500)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v52 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_17_51_37_2021_192)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v49 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_16_53_11_2021_575)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v51 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_12_10_39_2021_432)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v48 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Mar__5_17_18_56_2021_497)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v51 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_12_10_39_2021_432)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v49 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_16_53_11_2021_575)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v50 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_18_29_34_2021_806)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v49 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_16_53_11_2021_575)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v47 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_21_12_03_48_2021_284)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v51 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_12_10_39_2021_432)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v49 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_16_53_11_2021_575)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v46 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_14_15_14_25_2021_903)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v46 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_14_15_14_25_2021_903)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v52 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_17_51_37_2021_192)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v45 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Jan__8_10_24_34_2021_185)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v49 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_16_53_11_2021_575)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v52 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_17_51_37_2021_192)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v56 6/6] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar_16_10_27_55_2021_500)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v45 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Jan__8_10_24_34_2021_185)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v46 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_14_15_14_25_2021_903)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v48 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Mar__5_17_18_56_2021_497)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v49 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_16_53_11_2021_575)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v57 6/6] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index 84b22f4ac9..a2c88bd3a4 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Mar_18_16_56_02_2021_947)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v56 6/6] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar_16_10_27_55_2021_500)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v49 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_16_53_11_2021_575)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v56 6/6] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar_16_10_27_55_2021_500)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v56 6/6] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar_16_10_27_55_2021_500)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v47 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_21_12_03_48_2021_284)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v52 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_17_51_37_2021_192)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v48 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Mar__5_17_18_56_2021_497)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v52 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_17_51_37_2021_192)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v50 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_18_29_34_2021_806)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v45 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Jan__8_10_24_34_2021_185)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v46 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_14_15_14_25_2021_903)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v52 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_17_51_37_2021_192)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v50 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_18_29_34_2021_806)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v48 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Mar__5_17_18_56_2021_497)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v48 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Mar__5_17_18_56_2021_497)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v51 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_12_10_39_2021_432)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v56 6/6] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar_16_10_27_55_2021_500)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v38 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index 25eabbb1ad..dd35920e82 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.18.4
----Next_Part(Thu_Oct__1_09_07_22_2020_252)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v48 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Mar__5_17_18_56_2021_497)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v56 6/6] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar_16_10_27_55_2021_500)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v56 6/6] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar_16_10_27_55_2021_500)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v51 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_12_10_39_2021_432)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v51 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_12_10_39_2021_432)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v52 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_17_51_37_2021_192)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v46 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_14_15_14_25_2021_903)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v48 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Mar__5_17_18_56_2021_497)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v46 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_14_15_14_25_2021_903)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v50 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_18_29_34_2021_806)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v48 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Mar__5_17_18_56_2021_497)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v50 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_18_29_34_2021_806)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v43 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index 2b2761a588..eaf4448943 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Dec_11_16_50_03_2020_915)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v51 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_12_10_39_2021_432)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v51 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_12_10_39_2021_432)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v52 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_17_51_37_2021_192)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v46 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_14_15_14_25_2021_903)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v49 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_16_53_11_2021_575)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v47 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_21_12_03_48_2021_284)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v45 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Jan__8_10_24_34_2021_185)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v47 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_21_12_03_48_2021_284)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v51 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_12_10_39_2021_432)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v47 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_21_12_03_48_2021_284)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v47 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_21_12_03_48_2021_284)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v47 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_21_12_03_48_2021_284)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v48 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Mar__5_17_18_56_2021_497)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v50 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_18_29_34_2021_806)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v51 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_12_10_39_2021_432)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v52 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_17_51_37_2021_192)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v42 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index 25eabbb1ad..dd35920e82 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.18.4
----Next_Part(Wed_Nov_11_10_07_22_2020_796)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v52 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_17_51_37_2021_192)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v56 6/6] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar_16_10_27_55_2021_500)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v45 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Jan__8_10_24_34_2021_185)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v46 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_14_15_14_25_2021_903)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v47 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_21_12_03_48_2021_284)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v45 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Jan__8_10_24_34_2021_185)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v40 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index 25eabbb1ad..dd35920e82 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.18.4
----Next_Part(Wed_Nov__4_17_39_10_2020_208)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v50 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_18_29_34_2021_806)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v51 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_12_10_39_2021_432)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v46 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_14_15_14_25_2021_903)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v48 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Mar__5_17_18_56_2021_497)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v52 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_17_51_37_2021_192)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v46 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_14_15_14_25_2021_903)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v56 6/6] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar_16_10_27_55_2021_500)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v45 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Jan__8_10_24_34_2021_185)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v56 6/6] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar_16_10_27_55_2021_500)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v49 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_16_53_11_2021_575)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v49 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_16_53_11_2021_575)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v47 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_21_12_03_48_2021_284)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v48 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Mar__5_17_18_56_2021_497)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v49 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_16_53_11_2021_575)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v46 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_14_15_14_25_2021_903)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v47 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_21_12_03_48_2021_284)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v47 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_21_12_03_48_2021_284)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v50 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_18_29_34_2021_806)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v45 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Jan__8_10_24_34_2021_185)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v56 6/6] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar_16_10_27_55_2021_500)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v47 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_21_12_03_48_2021_284)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v56 6/6] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar_16_10_27_55_2021_500)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v49 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_16_53_11_2021_575)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v52 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_17_51_37_2021_192)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v47 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_21_12_03_48_2021_284)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v47 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_21_12_03_48_2021_284)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v48 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Mar__5_17_18_56_2021_497)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v56 6/6] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar_16_10_27_55_2021_500)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v50 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_18_29_34_2021_806)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v50 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_18_29_34_2021_806)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v45 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Jan__8_10_24_34_2021_185)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v45 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Jan__8_10_24_34_2021_185)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v49 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_16_53_11_2021_575)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v45 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Jan__8_10_24_34_2021_185)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v49 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_16_53_11_2021_575)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v45 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Jan__8_10_24_34_2021_185)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v46 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_14_15_14_25_2021_903)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v51 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_12_10_39_2021_432)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v56 6/6] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar_16_10_27_55_2021_500)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v39 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index 25eabbb1ad..dd35920e82 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.18.4
----Next_Part(Tue_Oct__6_10_06_44_2020_382)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v52 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_17_51_37_2021_192)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v51 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_12_10_39_2021_432)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v52 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_17_51_37_2021_192)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v49 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_16_53_11_2021_575)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v50 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_18_29_34_2021_806)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v48 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Mar__5_17_18_56_2021_497)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v46 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_14_15_14_25_2021_903)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v52 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_17_51_37_2021_192)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v47 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_21_12_03_48_2021_284)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v48 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Mar__5_17_18_56_2021_497)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v52 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_17_51_37_2021_192)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v56 6/6] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar_16_10_27_55_2021_500)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v50 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_18_29_34_2021_806)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v46 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_14_15_14_25_2021_903)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v50 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_18_29_34_2021_806)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v45 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Jan__8_10_24_34_2021_185)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v56 6/6] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar_16_10_27_55_2021_500)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v49 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_16_53_11_2021_575)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v50 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_18_29_34_2021_806)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v52 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_17_51_37_2021_192)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v51 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_12_10_39_2021_432)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v52 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_17_51_37_2021_192)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v46 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_14_15_14_25_2021_903)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v50 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_18_29_34_2021_806)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v49 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_16_53_11_2021_575)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v51 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_12_10_39_2021_432)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v45 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Jan__8_10_24_34_2021_185)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v47 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_21_12_03_48_2021_284)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v51 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_12_10_39_2021_432)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v50 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_18_29_34_2021_806)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v45 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Jan__8_10_24_34_2021_185)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v45 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Jan__8_10_24_34_2021_185)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v50 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_18_29_34_2021_806)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v49 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_16_53_11_2021_575)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v46 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_14_15_14_25_2021_903)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v48 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Mar__5_17_18_56_2021_497)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v52 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_17_51_37_2021_192)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v50 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_18_29_34_2021_806)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v48 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Mar__5_17_18_56_2021_497)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v52 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_17_51_37_2021_192)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v56 6/6] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar_16_10_27_55_2021_500)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v56 6/6] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar_16_10_27_55_2021_500)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v47 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Thu_Jan_21_12_03_48_2021_284)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v48 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Mar__5_17_18_56_2021_497)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v49 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_16_53_11_2021_575)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v52 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Wed_Mar_10_17_51_37_2021_192)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v50 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index f0d75f55bd..f54fcec70a 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Tue_Mar__9_18_29_34_2021_806)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* [PATCH v45 7/7] Exclude pg_stat directory from base backup
@ 2020-09-29 14:19 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Kyotaro Horiguchi @ 2020-09-29 14:19 UTC (permalink / raw)
basebackup sends the content of pg_stat directory, which is doomed to
be removed at startup from the backup. Now that pg_stat_statements
saves a temporary file into the directory, let exclude pg_stat
directory from a base backup.
---
src/backend/replication/basebackup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c
index d2c3064678..25677c5c6e 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -149,6 +149,13 @@ struct exclude_list_item
*/
static const char *const excludeDirContents[] =
{
+ /*
+ * Skip statistics files. PGSTAT_STAT_PERMANENT_DIRECTORY must be skipped
+ * because the files in the directory will be removed at startup from the
+ * backup.
+ */
+ PGSTAT_STAT_PERMANENT_DIRECTORY,
+
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another primary. See backup.sgml
--
2.27.0
----Next_Part(Fri_Jan__8_10_24_34_2021_185)----
^ permalink raw reply [nested|flat] 277+ messages in thread
* windows CI failing PMSignalState->PMChildFlags[slot] == PM_CHILD_ASSIGNED
@ 2023-02-08 01:28 Andres Freund <[email protected]>
0 siblings, 0 replies; 277+ messages in thread
From: Andres Freund @ 2023-02-08 01:28 UTC (permalink / raw)
To: pgsql-hackers; Thomas Munro <[email protected]>
Hi,
A recent cfbot run caused CI on windows to crash - on a patch that could not
conceivably cause this issue:
https://cirrus-ci.com/task/5646021133336576
the patch is just:
https://github.com/postgresql-cfbot/postgresql/commit/dbd4afa6e7583c036b86abe2e3d27b508d335c2b
regression.diffs: https://api.cirrus-ci.com/v1/artifact/task/5646021133336576/testrun/build/testrun/regress/regress/re...
postmaster.log: https://api.cirrus-ci.com/v1/artifact/task/5646021133336576/testrun/build/testrun/regress/regress/lo...
crash info: https://api.cirrus-ci.com/v1/artifact/task/5646021133336576/crashlog/crashlog-postgres.exe_1af0_2023...
00000085`f03ffa40 00007ff6`fd89faa8 ucrtbased!abort(void)+0x5a [minkernel\crts\ucrt\src\appcrt\startup\abort.cpp @ 77]
00000085`f03ffa80 00007ff6`fd6474dc postgres!ExceptionalCondition(
char * conditionName = 0x00007ff6`fdd03ca8 "PMSignalState->PMChildFlags[slot] == PM_CHILD_ASSIGNED",
char * fileName = 0x00007ff6`fdd03c80 "../src/backend/storage/ipc/pmsignal.c",
int lineNumber = 0n329)+0x78 [c:\cirrus\src\backend\utils\error\assert.c @ 67]
00000085`f03ffac0 00007ff6`fd676eff postgres!MarkPostmasterChildActive(void)+0x7c [c:\cirrus\src\backend\storage\ipc\pmsignal.c @ 329]
00000085`f03ffb00 00007ff6`fd59aa3a postgres!InitProcess(void)+0x2ef [c:\cirrus\src\backend\storage\lmgr\proc.c @ 375]
00000085`f03ffb60 00007ff6`fd467689 postgres!SubPostmasterMain(
int argc = 0n3,
char ** argv = 0x000001c6`f3814e80)+0x33a [c:\cirrus\src\backend\postmaster\postmaster.c @ 4962]
00000085`f03ffd90 00007ff6`fda0e1c9 postgres!main(
int argc = 0n3,
char ** argv = 0x000001c6`f3814e80)+0x2f9 [c:\cirrus\src\backend\main\main.c @ 192]
So, somehow we ended up a pmsignal slot for a new backend that's not currently
in PM_CHILD_ASSIGNED state.
Obviously the first idea is to wonder whether this is a problem introduced as
part of the the recent postmaster-latchification work.
At first I thought we were failing to terminate running processes, due to the
following output:
parallel group (20 tests): name char txid text varchar enum float8 regproc int2 boolean bit oid pg_lsn int8 int4 float4 uuid rangetypes numeric money
boolean ... ok 684 ms
char ... ok 517 ms
name ... ok 354 ms
varchar ... ok 604 ms
text ... ok 603 ms
int2 ... ok 676 ms
int4 ... ok 818 ms
int8 ... ok 779 ms
oid ... ok 720 ms
float4 ... ok 823 ms
float8 ... ok 628 ms
bit ... ok 666 ms
numeric ... ok 1132 ms
txid ... ok 497 ms
uuid ... ok 818 ms
enum ... ok 619 ms
money ... FAILED (test process exited with exit code 2) 7337 ms
rangetypes ... ok 813 ms
pg_lsn ... ok 762 ms
regproc ... ok 632 ms
But now I realize the reason none of the other tests failed, is because the
crash took a long time, presumably due to the debugger creating the above
information, so no other tests failed.
2023-02-08 00:53:20.257 GMT client backend[4584] pg_regress/rangetypes STATEMENT: select '-[a,z)'::textrange;
TRAP: failed Assert("PMSignalState->PMChildFlags[slot] == PM_CHILD_ASSIGNED"), File: "../src/backend/storage/ipc/pmsignal.c", Line: 329, PID: 5948
[ quite a few lines ]
2023-02-08 00:53:27.420 GMT postmaster[872] LOG: server process (PID 5948) was terminated by exception 0xC0000354
2023-02-08 00:53:27.420 GMT postmaster[872] HINT: See C include file "ntstatus.h" for a description of the hexadecimal value.
2023-02-08 00:53:27.420 GMT postmaster[872] LOG: terminating any other active server processes
2023-02-08 00:53:27.434 GMT postmaster[872] LOG: all server processes terminated; reinitializing
2023-02-08 00:53:27.459 GMT startup[5800] LOG: database system was interrupted; last known up at 2023-02-08 00:53:19 GMT
2023-02-08 00:53:27.459 GMT startup[5800] LOG: database system was not properly shut down; automatic recovery in progress
2023-02-08 00:53:27.462 GMT startup[5800] LOG: redo starts at 0/20DCF08
2023-02-08 00:53:27.484 GMT startup[5800] LOG: could not stat file "pg_tblspc/16502": No such file or directory
2023-02-08 00:53:27.484 GMT startup[5800] CONTEXT: WAL redo at 0/20DCFB8 for Tablespace/DROP: 16502
2023-02-08 00:53:27.614 GMT startup[5800] LOG: invalid record length at 0/25353E8: wanted 24, got 0
2023-02-08 00:53:27.614 GMT startup[5800] LOG: redo done at 0/2534FE0 system usage: CPU: user: 0.04 s, system: 0.04 s, elapsed: 0.15 s
Nevertheless, clearly this should never be reached.
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 277+ messages in thread
end of thread, other threads:[~2023-02-08 01:28 UTC | newest]
Thread overview: 277+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2017-03-01 08:56 Re: Partition-wise join for join between (declaratively) partitioned tables Ashutosh Bapat <[email protected]>
2017-03-02 04:52 ` Ashutosh Bapat <[email protected]>
2017-03-09 01:14 ` Robert Haas <[email protected]>
2017-03-10 10:43 ` Ashutosh Bapat <[email protected]>
2017-03-13 19:24 ` Robert Haas <[email protected]>
2017-03-14 00:17 ` Robert Haas <[email protected]>
2017-03-14 00:58 ` Amit Langote <[email protected]>
2017-03-14 12:04 ` Ashutosh Bapat <[email protected]>
2017-03-14 12:04 ` Ashutosh Bapat <[email protected]>
2017-03-14 12:04 ` Ashutosh Bapat <[email protected]>
2017-03-15 00:33 ` Robert Haas <[email protected]>
2017-03-15 01:21 ` Robert Haas <[email protected]>
2017-03-15 12:55 ` Ashutosh Bapat <[email protected]>
2017-03-15 19:05 ` Robert Haas <[email protected]>
2017-03-16 01:40 ` Robert Haas <[email protected]>
2017-03-16 11:19 ` Ashutosh Bapat <[email protected]>
2017-03-16 15:06 ` Robert Haas <[email protected]>
2017-03-16 10:51 ` Ashutosh Bapat <[email protected]>
2017-03-15 12:49 ` Ashutosh Bapat <[email protected]>
2017-03-15 19:00 ` Robert Haas <[email protected]>
2017-03-16 10:48 ` Ashutosh Bapat <[email protected]>
2017-03-16 15:05 ` Robert Haas <[email protected]>
2017-03-17 10:28 ` Ashutosh Bapat <[email protected]>
2017-03-17 13:15 ` Ashutosh Bapat <[email protected]>
2017-03-18 00:10 ` Robert Haas <[email protected]>
2017-03-19 04:15 ` Rafia Sabih <[email protected]>
2017-03-20 02:39 ` Robert Haas <[email protected]>
2017-03-20 02:51 ` Robert Haas <[email protected]>
2017-03-20 13:44 ` Ashutosh Bapat <[email protected]>
2017-03-20 16:29 ` Robert Haas <[email protected]>
2017-03-20 16:07 ` Rafia Sabih <[email protected]>
2017-03-20 16:40 ` Robert Haas <[email protected]>
2017-03-20 16:47 ` Ashutosh Bapat <[email protected]>
2017-03-21 11:41 ` Ashutosh Bapat <[email protected]>
2017-03-21 14:39 ` Robert Haas <[email protected]>
2017-03-20 13:44 ` Ashutosh Bapat <[email protected]>
2017-03-20 16:28 ` Robert Haas <[email protected]>
2017-03-20 16:52 ` Ashutosh Bapat <[email protected]>
2017-03-20 16:56 ` Robert Haas <[email protected]>
2017-03-20 17:19 ` Ashutosh Bapat <[email protected]>
2017-03-20 18:03 ` Robert Haas <[email protected]>
2017-03-21 10:22 ` Rajkumar Raghuwanshi <[email protected]>
2017-03-21 14:19 ` Ashutosh Bapat <[email protected]>
2017-03-21 11:46 ` Ashutosh Bapat <[email protected]>
2017-03-21 17:10 ` Ashutosh Bapat <[email protected]>
2017-03-22 08:17 ` Rafia Sabih <[email protected]>
2017-03-22 09:49 ` Ashutosh Bapat <[email protected]>
2017-03-22 12:01 ` Rafia Sabih <[email protected]>
2017-03-22 12:47 ` Ashutosh Bapat <[email protected]>
2017-03-22 12:46 ` Ashutosh Bapat <[email protected]>
2017-03-22 13:02 ` Robert Haas <[email protected]>
2017-03-22 13:59 ` Ashutosh Bapat <[email protected]>
2017-03-22 17:16 ` Robert Haas <[email protected]>
2017-03-23 04:22 ` Ashutosh Bapat <[email protected]>
2017-03-22 19:47 ` Robert Haas <[email protected]>
2017-03-23 12:48 ` Ashutosh Bapat <[email protected]>
2019-01-30 06:28 Question on compatibility of Postgres with Open JDK Pratheej Chandrika <[email protected]>
2019-01-30 06:33 ` Re: [BDR] Question on compatibility of Postgres with Open JDK Craig Ringer <[email protected]>
2019-01-30 07:28 ` Re: [BDR] Question on compatibility of Postgres with Open JDK Pratheej Chandrika <[email protected]>
2019-01-30 08:27 ` Re: [BDR] Question on compatibility of Postgres with Open JDK Craig Ringer <[email protected]>
2020-09-29 14:19 [PATCH v56 6/6] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v44 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v50 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v45 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v50 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v50 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v47 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v56 6/6] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v48 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v49 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v52 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v51 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v46 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v48 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v51 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v45 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v45 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v50 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v47 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v48 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v48 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v47 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v49 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v51 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v51 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v52 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v48 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v57 6/6] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v46 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v47 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v46 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v51 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v49 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v46 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v49 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v52 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v51 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v48 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v56 6/6] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v46 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v51 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v49 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v45 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v56 6/6] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v48 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v41 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v56 6/6] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v50 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v51 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v56 6/6] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v52 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v49 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v51 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v48 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v51 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v49 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v50 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v49 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v47 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v51 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v49 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v46 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v46 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v52 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v45 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v49 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v52 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v56 6/6] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v45 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v46 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v48 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v49 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v57 6/6] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v56 6/6] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v49 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v56 6/6] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v56 6/6] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v47 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v52 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v48 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v52 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v50 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v45 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v46 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v52 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v50 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v48 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v48 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v51 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v56 6/6] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v38 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v48 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v56 6/6] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v56 6/6] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v51 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v51 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v52 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v46 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v48 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v46 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v50 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v48 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v50 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v43 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v51 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v51 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v52 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v46 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v49 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v47 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v45 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v47 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v51 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v47 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v47 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v47 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v48 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v50 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v51 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v52 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v42 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v52 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v56 6/6] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v45 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v46 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v47 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v45 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v40 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v50 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v51 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v46 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v48 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v52 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v46 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v56 6/6] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v45 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v56 6/6] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v49 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v49 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v47 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v48 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v49 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v46 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v47 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v47 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v50 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v45 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v56 6/6] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v47 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v56 6/6] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v49 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v52 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v47 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v47 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v48 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v56 6/6] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v50 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v50 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v45 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v45 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v49 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v45 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v49 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v45 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v46 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v51 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v56 6/6] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v39 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v52 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v51 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v52 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v49 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v50 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v48 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v46 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v52 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v47 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v48 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v52 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v56 6/6] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v50 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v46 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v50 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v45 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v56 6/6] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v49 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v50 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v52 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v51 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v52 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v46 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v50 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v49 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v51 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v45 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v47 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v51 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v50 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v45 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v45 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v50 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v49 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v46 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v48 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v52 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v50 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v48 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v52 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v56 6/6] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v56 6/6] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v47 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v48 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v49 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v52 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v50 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2020-09-29 14:19 [PATCH v45 7/7] Exclude pg_stat directory from base backup Kyotaro Horiguchi <[email protected]>
2023-02-08 01:28 windows CI failing PMSignalState->PMChildFlags[slot] == PM_CHILD_ASSIGNED Andres Freund <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox