Обсуждение: Unable to drop extension dblink
In the process of removing extensions not required on the database I was in the process of removing the dblink extension from the postgres database. First attempt to drop the extension failed with 'ERROR: schema "ag_catalog" does not exist'. Created the extension and then received the 'ERROR: table "ag_label" does not exist'. In response I created the table with a dummy colum 'label'. Dropping the extension resulted in "ERROR: index "pgsql-admin@lists.postgresql.org"'. So I created the index. Next attempt resulted in 'ERROR: column is not in index'. Now I appear to be stuck in a loop with 'ERROR: column is not in index' regardless of any attempt to remove these tables and the original extension. Any assistance appreciated. Regards Matt.
On Monday, September 18, 2023, Matt Gibbins <matt_gibbins@fastmail.com.au> wrote:
In the process of removing extensions not required on the database I was in the process of removing the dblink extension from the postgres database.
First attempt to drop the extension failed with 'ERROR: schema "ag_catalog" does not exist'.
Created the extension and then received the 'ERROR: table "ag_label" does not exist'.
In response I created the table with a dummy colum 'label'.
Dropping the extension resulted in "ERROR: index "pgsql-admin@lists.postgresql.org"'. So I created the index.
Next attempt resulted in 'ERROR: column is not in index'.
Now I appear to be stuck in a loop with 'ERROR: column is not in index' regardless of any attempt to remove these tables and the original extension.
Any assistance appreciated.
Is the output really that corrupted or is your writing of the email introducing typos and whatnot that aren’t actually being shown by the system?
I’d probably hope my backup isn’t corrupted and restore into a newly created instance where the extension manipulation just works.
David J.
Matt Gibbins <matt_gibbins@fastmail.com.au> writes: > In the process of removing extensions not required on the database I was > in the process of removing the dblink extension from the postgres database. > First attempt to drop the extension failed with 'ERROR: schema > "ag_catalog" does not exist'. Something is very broken there. I wonder if this error could be a corrupted reference to "pg_catalog" --- but I don't really see what the details could be, because we don't store schema references as textual names, rather OIDs. Your follow-on errors also look more like catalog corruption than anything sane. With only these limited factoids to look at, it's impossible to say just what's going on --- but creating bogus objects in response to these errors is unlikely to get you anywhere. What PG version is this, what's the installation's history, have you suffered any catastrophic failures in the recent past? regards, tom lane
On 19/9/23 11:16, Tom Lane wrote: > Matt Gibbins <matt_gibbins@fastmail.com.au> writes: >> In the process of removing extensions not required on the database I was >> in the process of removing the dblink extension from the postgres database. >> First attempt to drop the extension failed with 'ERROR: schema >> "ag_catalog" does not exist'. > Something is very broken there. I wonder if this error could be a > corrupted reference to "pg_catalog" --- but I don't really see what > the details could be, because we don't store schema references as > textual names, rather OIDs. Your follow-on errors also look more > like catalog corruption than anything sane. With only these limited > factoids to look at, it's impossible to say just what's going on > --- but creating bogus objects in response to these errors is > unlikely to get you anywhere. What PG version is this, what's > the installation's history, have you suffered any catastrophic > failures in the recent past? > > regards, tom lane Tom Thanks. The PG version information is PostgreSQL 15.4 (Debian 15.4-2.pgdg120+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14) 12.2.0, 64-bit. The database was upgraded from version 13 to 15 in March this year. This problem has only just now started occurring. Not aware of any catastrophic failures. Though have had instances of queries segfaulting. Regards Matt