Re: vac_update_datfrozenxid will raise "wrong tuple length" if pg_database tuple contains toast attribute. - Mailing list pgsql-hackers

From Ashwin Agrawal
Subject Re: vac_update_datfrozenxid will raise "wrong tuple length" if pg_database tuple contains toast attribute.
Date
Msg-id CAKSySweBLznbQ5b7yJXVJYMbCB_VU-pGjFFNY-QmnnstNz11cg@mail.gmail.com
Whole thread Raw
In response to Re: vac_update_datfrozenxid will raise "wrong tuple length" if pg_database tuple contains toast attribute.  (Michael Paquier <michael@paquier.xyz>)
Responses Re: vac_update_datfrozenxid will raise "wrong tuple length" if pg_database tuple contains toast attribute.
List pgsql-hackers
On Sun, Nov 29, 2020 at 5:27 PM Michael Paquier <michael@paquier.xyz> wrote:
> One thing that strikes me as unwise is that we could run into similar
> problems with vac_update_relstats() in the future, and there have been
> recent talks about having more toast tables like for pg_class.  That
> is not worth caring about on stable branches because it is not an
> active problem there, but we could do something better on HEAD.

For now, I have added just a comment at the top of
heap_inplace_update() to warn callers.

I am thinking if there is some way to assert this aspect, but seems no way.
So, yes, having at least a comment is good for now.

Junfeng and Ashwin also mentioned to me off-list that their patch used
a second copy for performance reasons, but I don't see why this could
become an issue as we update each pg_database row only once a job is
done.  So I'd like to apply something like the attached on HEAD,
comments are welcome. 

Yes the attached patch looks good to me for PostgreSQL. Thanks Michael.
(In Greenplum, due to per table dispatch to segments, during database wide
vacuum this function gets called per table instead of only at the end, hence
we were trying to be conservative.)

pgsql-hackers by date:

Previous
From: James Coleman
Date:
Subject: Re: [DOC] Document concurrent index builds waiting on each other
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: Huge memory consumption on partitioned table with FKs