From: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Petr Vejsada <pve(at)paymorrow(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: pg_upgrade (12->14) fails on aggregate |
Date: | 2022-06-17 02:01:03 |
Message-ID: | 20220617020103.GG29853@telsasoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
On Wed, Jun 15, 2022 at 03:32:04PM -0400, Tom Lane wrote:
> Justin Pryzby <pryzby(at)telsasoft(dot)com> writes:
> > But Petr has a point - pg_upgrade should aspire to catch errors in --check,
> > rather than starting and then leaving a mess behind for the user to clean up
>
> Agreed; pg_upgrade has historically tried to find problems similar to
> this. However, it's not just aggregates that are at risk. People
> might also have built user-defined plain functions, or operators,
> atop these functions. How far do we want to go in looking?
I wasn't yet able to construct a user-defined function which fails to reload.
> As for the query, I think it could be simplified quite a bit by
> relying on regprocedure literals, that is something like
Yes, thanks.
> Also, I think you need to check aggfinalfn too.
Done but maybe needs more cleanup.
> Also, I'd be inclined to reject system-provided objects by checking
> for OID >= 16384 rather than hard-wiring assumptions about things
> being in pg_catalog or not.
To me, oid>=16384 seems more hard-wired than namespace!='pg_catalog'.
This patch also resolves an issue with PQfinish()/dangling connections.
--
Justin
Attachment | Content-Type | Size |
---|---|---|
0001-WIP-pg_upgrade-check-detect-old-polymorphics-from-pr.patch | text/x-diff | 5.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | PG Bug reporting form | 2022-06-17 12:03:16 | BUG #17522: While using --with-ssl=openssl and PG_TEST_EXTRA='ssl' options, SSL test fails on OpenBSD 7.1 |
Previous Message | Jon SCHEWE | 2022-06-16 22:31:51 | Trouble with pgpool-II-pcp packaging |
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2022-06-17 02:14:54 | Re: PG 15 (and to a smaller degree 14) regression due to ExprEvalStep size |
Previous Message | Kyotaro Horiguchi | 2022-06-17 00:43:58 | Re: fix stats_fetch_consistency value in postgresql.conf.sample |