public inbox for [email protected]help / color / mirror / Atom feed
[PATCH v8 8/8] pg_dump: partitioned index depend on its partitions 3+ messages / 3 participants [nested] [flat]
* [PATCH v8 8/8] pg_dump: partitioned index depend on its partitions @ 2020-11-25 23:34 Justin Pryzby <[email protected]> 0 siblings, 0 replies; 3+ messages in thread From: Justin Pryzby @ 2020-11-25 23:34 UTC (permalink / raw) This is required for restoring clustered parent index, which is marked INVALID until indexes have been built on all its child tables, and it's prohibited to CLUSTER ON an INVALID index See also: 8cff4f5348d075e063100071013f00a900c32b0f --- src/backend/commands/tablecmds.c | 6 +++--- src/bin/pg_dump/common.c | 8 ++++++++ 2 files changed, 11 insertions(+), 3 deletions(-) diff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c index 420991e315..a478c13990 100644 --- a/src/backend/commands/tablecmds.c +++ b/src/backend/commands/tablecmds.c @@ -17521,6 +17521,9 @@ validatePartitionedIndex(Relation partedIdx, Relation partedTbl) table_close(idxRel, RowExclusiveLock); } + /* make sure we see the validation we just did */ + CommandCounterIncrement(); + /* * If this index is in turn a partition of a larger index, validating it * might cause the parent to become valid also. Try that. @@ -17532,9 +17535,6 @@ validatePartitionedIndex(Relation partedIdx, Relation partedTbl) Relation parentIdx, parentTbl; - /* make sure we see the validation we just did */ - CommandCounterIncrement(); - parentIdxId = get_partition_parent(RelationGetRelid(partedIdx)); parentTblId = get_partition_parent(RelationGetRelid(partedTbl)); parentIdx = relation_open(parentIdxId, AccessExclusiveLock); diff --git a/src/bin/pg_dump/common.c b/src/bin/pg_dump/common.c index 1a261a5545..cdfba058fc 100644 --- a/src/bin/pg_dump/common.c +++ b/src/bin/pg_dump/common.c @@ -429,6 +429,12 @@ flagInhIndexes(Archive *fout, TableInfo tblinfo[], int numTables) attachinfo[k].parentIdx = parentidx; attachinfo[k].partitionIdx = index; + /* + * We want dependencies from parent to partition (so that the + * partition index is created first) + */ + addObjectDependency(&parentidx->dobj, index->dobj.dumpId); + /* * We must state the DO_INDEX_ATTACH object's dependencies * explicitly, since it will not match anything in pg_depend. @@ -446,6 +452,8 @@ flagInhIndexes(Archive *fout, TableInfo tblinfo[], int numTables) */ addObjectDependency(&attachinfo[k].dobj, index->dobj.dumpId); addObjectDependency(&attachinfo[k].dobj, parentidx->dobj.dumpId); + // addObjectDependency(&parentidx->dobj, attachinfo[k].dobj.dumpId); + addObjectDependency(&attachinfo[k].dobj, index->indextable->dobj.dumpId); addObjectDependency(&attachinfo[k].dobj, -- 2.17.0 --O5XBE6gyVG5Rl6Rj-- ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: standby recovery fails (tablespace related) (tentative patch and discussion) @ 2022-04-01 04:21 Kyotaro Horiguchi <[email protected]> 2022-04-01 18:51 ` Re: standby recovery fails (tablespace related) (tentative patch and discussion) Robert Haas <[email protected]> 0 siblings, 1 reply; 3+ messages in thread From: Kyotaro Horiguchi @ 2022-04-01 04:21 UTC (permalink / raw) To: [email protected]; +Cc: [email protected]; [email protected]; [email protected]; pgsql-hackers At Tue, 29 Mar 2022 09:31:42 -0400, Robert Haas <[email protected]> wrote in > On Tue, Mar 29, 2022 at 9:28 AM Alvaro Herrera <[email protected]> wrote: > > OK, this is a bug that's been open for years. A fix can be committed > > after the feature freeze anyway. > > +1 By the way, may I ask how do we fix this? The existing recovery code already generates just-to-be-delete files in a real directory in pg_tblspc sometimes, and elsewise skip applying WAL records on nonexistent heap pages. It is the "mixed" way. 1. stop XLogReadBufferForRedo creating a file in nonexistent directories then remember the failure (I'm not sure how big the impact is.) 2. unconditionally create all objects required for recovery to proceed.. 2.1 and igore the failures. 2.2 and remember the failures. 3. Any other? 2 needs to create a real directory in pg_tblspc. So 1? regards. -- Kyotaro Horiguchi NTT Open Source Software Center ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: standby recovery fails (tablespace related) (tentative patch and discussion) 2022-04-01 04:21 Re: standby recovery fails (tablespace related) (tentative patch and discussion) Kyotaro Horiguchi <[email protected]> @ 2022-04-01 18:51 ` Robert Haas <[email protected]> 0 siblings, 0 replies; 3+ messages in thread From: Robert Haas @ 2022-04-01 18:51 UTC (permalink / raw) To: Kyotaro Horiguchi <[email protected]>; +Cc: Alvaro Herrera <[email protected]>; Michael Paquier <[email protected]>; Julien Rouhaud <[email protected]>; pgsql-hackers On Fri, Apr 1, 2022 at 12:22 AM Kyotaro Horiguchi <[email protected]> wrote: > By the way, may I ask how do we fix this? The existing recovery code > already generates just-to-be-delete files in a real directory in > pg_tblspc sometimes, and elsewise skip applying WAL records on > nonexistent heap pages. It is the "mixed" way. Can you be more specific about where we have each behavior now? > 1. stop XLogReadBufferForRedo creating a file in nonexistent > directories then remember the failure (I'm not sure how big the > impact is.) > > 2. unconditionally create all objects required for recovery to proceed.. > 2.1 and igore the failures. > 2.2 and remember the failures. > > 3. Any other? > > 2 needs to create a real directory in pg_tblspc. So 1? I think we could either do 1 or 2. My intuition is that getting 2 working would be less scary and more likely to be something we would feel comfortable back-patching, but 1 is probably a better design in the long term. However, I might be wrong -- that's just a guess. -- Robert Haas EDB: http://www.enterprisedb.com ^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2022-04-01 18:51 UTC | newest] Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2020-11-25 23:34 [PATCH v8 8/8] pg_dump: partitioned index depend on its partitions Justin Pryzby <[email protected]> 2022-04-01 04:21 Re: standby recovery fails (tablespace related) (tentative patch and discussion) Kyotaro Horiguchi <[email protected]> 2022-04-01 18:51 ` Re: standby recovery fails (tablespace related) (tentative patch and discussion) Robert Haas <[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