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 20200228082429.GH2688@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?
List pgsql-hackers
On Tue, Feb 25, 2020 at 10:44:40PM +0100, Daniel Gustafsson wrote:
> In doing that I realized that there is another hunk in this patch for fixing up
> logical decoding multi-insert support, which is independent of the patch in
> question here so I split it off.  It's another issue which cause no harm at all
> today, but fails as soon as someone tries to perform multi inserts into the
> catalog.

Yep.  I was wondering how we should do that for some time, but I was
not able to come back to it.

+   /*
+    * CONTAINS_NEW_TUPLE will always be set unless the multi_insert was
+    * performed for a catalog.  If it is a catalog, return immediately as
+    * there is nothing to logically decode.
+    */
+   if (!(xlrec->flags & XLH_INSERT_CONTAINS_NEW_TUPLE))
+       return;
Hmm, OK.  Consistency with DecodeInsert() is a good idea here, so
count me in regarding the way your patch handles the problem.  I would
be fine to apply that part but, Andres, perhaps you would prefer
taking care of it yourself?
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: "imai.yoshikazu@fujitsu.com"
Date:
Subject: RE: [Proposal] Add accumulated statistics for wait event
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: Make mesage at end-of-recovery less scary.