Re: Ought to use heap_multi_insert() for pg_attribute/dependinsertions? - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Ought to use heap_multi_insert() for pg_attribute/dependinsertions?
Date
Msg-id 20191126054410.GE5435@paquier.xyz
Whole thread Raw
In response to Re: Ought to use heap_multi_insert() for pg_attribute/dependinsertions?  (Daniel Gustafsson <daniel@yesql.se>)
Responses Re: Ought to use heap_multi_insert() for pg_attribute/dependinsertions?  (Daniel Gustafsson <daniel@yesql.se>)
List pgsql-hackers
On Sun, Nov 17, 2019 at 12:01:08AM +0100, Daniel Gustafsson wrote:
> Fixed by opting for the latter, mostly since it seems best convey what the
> function does.

-   recordMultipleDependencies(depender,
-                              context.addrs->refs, context.addrs->numrefs,
-                              behavior);
+   recordMultipleDependencies(depender, context.addrs->refs,
+                              context.addrs->numrefs, behavior);
Some noise diffs.

--- a/src/test/regress/expected/create_index.out
+++ b/src/test/regress/expected/create_index.out
  index concur_reindex_ind4                | column c1 of table
- index concur_reindex_ind4                | column c1 of table
  index concur_reindex_ind4                | column c2 of table
This removes a duplicated dependency with indexes using the same
column multiple times.  Guess that's good to get rid of, this was just
unnecessary bloat in pg_depend.

The regression tests of contrib/test_decoding are still failing here:
+ERROR:  could not resolve cmin/cmax of catalog tuple

Getting rid the duplication between InsertPgAttributeTuples() and
InsertPgAttributeTuple() would be nice.  You would basically finish by
just using a single slot when inserting one tuple..
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: logical decoding : exceeded maxAllocatedDescs for .spill files
Next
From: Amit Khandekar
Date:
Subject: Re: logical decoding : exceeded maxAllocatedDescs for .spill files