Re: vac_update_datfrozenxid will raise "wrong tuple length" if pg_database tuple contains toast attribute.

From: Ashwin Agrawal <ashwinstar(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Junfeng Yang <yjerome(at)vmware(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Ashwin Agrawal <aashwin(at)vmware(dot)com>
Subject: Re: vac_update_datfrozenxid will raise "wrong tuple length" if pg_database tuple contains toast attribute.
Date: 2020-12-01 00:37:14
Message-ID: CAKSySweBLznbQ5b7yJXVJYMbCB_VU-pGjFFNY-QmnnstNz11cg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Nov 29, 2020 at 5:27 PM Michael Paquier <michael(at)paquier(dot)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.)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2020-12-01 00:40:39 Re: Huge memory consumption on partitioned table with FKs
Previous Message James Coleman 2020-12-01 00:29:27 Re: [DOC] Document concurrent index builds waiting on each other