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: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Ought to use heap_multi_insert() for pg_attribute/depend insertions?
Date: 2019-11-11 08:32:01
Message-ID: 20191111083201.GC1418@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Aug 06, 2019 at 11:24:46AM +0900, Michael Paquier wrote:
> A comment in heap_multi_insert() needs to be updated because it
> becomes the case with your patch:
> /*
> * We don't use heap_multi_insert for catalog tuples yet, but
> * better be prepared...
> */
>
> There is also this one in DecodeMultiInsert()
> * CONTAINS_NEW_TUPLE will always be set currently as multi_insert
> * isn't used for catalogs, but better be future proof.

Applying the latest patch, this results in an assertion failure for
the tests of test_decoding.

> (I am going to comment on the assertion issue on the other thread, I
> got some suggestions about it.)

This part has resulted in 75c1921, and we could just change
DecodeMultiInsert() so as if there is no tuple data then we'd just
leave. However, I don't feel completely comfortable with that either
as it would be nice to still check that for normal relations we
*always* have a FPW available.

Daniel, your thoughts? I am switching the patch as waiting on
author.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2019-11-11 08:37:30 Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?
Previous Message Amit Kapila 2019-11-11 08:27:40 Re: dropdb --force