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.)
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 |