Re: Ought to use heap_multi_insert() for pg_attribute/depend insertions?

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Daniel Gustafsson <daniel(at)yesql(dot)se>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Ought to use heap_multi_insert() for pg_attribute/depend insertions?
Date: 2020-02-28 08:24:29
Message-ID: 20200228082429.GH2688@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2020-02-28 08:28:06 Re: Make mesage at end-of-recovery less scary.
Previous Message imai.yoshikazu@fujitsu.com 2020-02-28 08:16:57 RE: [Proposal] Add accumulated statistics for wait event