From: | 杨伯宇(长堂) <yangboyu(dot)yby(at)alibaba-inc(dot)com> |
---|---|
To: | "Daniel Gustafsson" <daniel(at)yesql(dot)se> |
Cc: | "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | 回复:Re: speed up pg_upgrade with large number of tables |
Date: | 2024-07-05 09:24:42 |
Message-ID: | b0ccd72a-ec6d-4612-a921-53ec62df882a.yangboyu.yby@alibaba-inc.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > So, I'm thinking, why not add a "--skip-check" option in pg_upgrade to skip it?
> > See "1-Skip_Compatibility_Check_v1.patch".
>
> How would a user know that nothing has changed in the cluster between running
> the check and running the upgrade with a skipped check? Considering how
> complicated it is to understand exactly what pg_upgrade does it seems like
> quite a large caliber footgun.
Indeed, it's not feasible to execute an concise check ensuring that nothing
has changed. However, in many cases, a cluster consistently executes the
same SQL commands. Thus, if we've verified that the cluster was compatible
30 minutes prior, there's a strong likelihood that it remains compatible now.
Therefore, adding such an 'trust-me' option may still be beneficial.
> I would be much more interested in making the check phase go faster, and indeed
> there is ongoing work in this area. Since it sounds like you have a dev and
> test environment with a big workload, testing those patches would be helpful.
> https://commitfest.postgresql.org/48/4995/ is one that comes to mind.
Very meaningful work! I will try it.
--
Best regards,
Yang Boyu
From | Date | Subject | |
---|---|---|---|
Next Message | Hayato Kuroda (Fujitsu) | 2024-07-05 09:51:22 | RE: Parallel heap vacuum |
Previous Message | Michael Paquier | 2024-07-05 09:16:18 | Re: Injection points: preloading and runtime arguments |