From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
---|---|
To: | Ed Sabol <edwardjsabol(at)gmail(dot)com>, "pgsql-admin(at)lists(dot)postgresql(dot)org" <pgsql-admin(at)lists(dot)postgresql(dot)org> |
Subject: | Re: pg_dump: WARNING: could not find operator |
Date: | 2023-07-12 06:26:02 |
Message-ID: | 2c5b816e55fb35405f7d7afad3a517866c89c671.camel@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
On Tue, 2023-07-11 at 18:30 -0400, Ed Sabol wrote:
> On Jul 11, 2023, at 6:24 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > While you could clean it up manually, pg_dump
> > is just going to omit those clauses from its output, so there's no
> > real need to do anything if that outcome is sufficient.
>
> I'm mainly concerned about the pg_upgrade going smoothly. I'd like to minimize
> downtime as much as possible. I was planning to use "pg_upgrade --link", if it matters.
Then you should test the upgrade first.
To find out which operators are causing the trouble, you can run queries like
SELECT * FROM pg_operator
WHERE oprcom IN (2234078, 2234199)
OR oprnegate IN (2234078, 2234199);
and test everything that uses these broken operators particularly well.
Yours,
Laurenz Albe
From | Date | Subject | |
---|---|---|---|
Next Message | Satalabaha Postgres | 2023-07-13 01:46:42 | Identify sessions and SQL's that are generating more write ahead logs |
Previous Message | Ed Sabol | 2023-07-11 22:30:12 | Re: pg_dump: WARNING: could not find operator |