Thread: Database Error (Bogus atrribute number 24....)
I am receiving the following error from Postgres 7.3.3 on Linux
Bogus attribute number 24 for vs_actfreighservices (a view).
This error is preventing me from doing a dump on the database's and I cannot delete the view that has the problem.
Is there a way I can work around this? I can access and use the database just fine, but without the ability to edit/delete views and or backup the database it's become quite a issue.
If anyone knows how I might fix this, please help.
Thanks,
Steven
Bogus attribute number 24 for vs_actfreighservices (a view).
This error is preventing me from doing a dump on the database's and I cannot delete the view that has the problem.
Is there a way I can work around this? I can access and use the database just fine, but without the ability to edit/delete views and or backup the database it's become quite a issue.
If anyone knows how I might fix this, please help.
Thanks,
Steven
Steven Tower <tower@towerhome.cx> writes: > I am receiving the following error from Postgres 7.3.3 on Linux > Bogus attribute number 24 for vs_actfreighservices (a view). Hm, can you tell us how you got into this fix? That shouldn't happen AFAICS. As far as getting out of the problem is concerned, if you don't need the view you could just manually delete its pg_class row: as superuser do delete from pg_class where relname = 'vs_actfreighservices' (if you have multiple views named vs_actfreighservices in different schemas, more selectivity would be needed). That should leave you in a state where you can run pg_dump. regards, tom lane
Thats the thing, I have no idea how I got into this. I was cutting and pasting the view from one database to another. Did a refresh, it didn't show, I pasted again, it allowed it and then all hell broke lose.
This was in pg_admin III.
Thanks for the fix, I will try, I can afford to lose it on all databases in the system, I have copies on 3 different systems. The issue is this one database that it happened on happens to be the one in production.
Steven
On Sat, 2003-11-08 at 11:05, Tom Lane wrote:
This was in pg_admin III.
Thanks for the fix, I will try, I can afford to lose it on all databases in the system, I have copies on 3 different systems. The issue is this one database that it happened on happens to be the one in production.
Steven
On Sat, 2003-11-08 at 11:05, Tom Lane wrote:
Steven Tower <tower@towerhome.cx> writes: > I am receiving the following error from Postgres 7.3.3 on Linux > Bogus attribute number 24 for vs_actfreighservices (a view). Hm, can you tell us how you got into this fix? That shouldn't happen AFAICS. As far as getting out of the problem is concerned, if you don't need the view you could just manually delete its pg_class row: as superuser do delete from pg_class where relname = 'vs_actfreighservices' (if you have multiple views named vs_actfreighservices in different schemas, more selectivity would be needed). That should leave you in a state where you can run pg_dump. regards, tom lane
Attachment
I just want to let you know your sugestion worked and allowed me to dump and restore the current database.
Thanks much,
Steven
On Sat, 2003-11-08 at 11:05, Tom Lane wrote:
Thanks much,
Steven
On Sat, 2003-11-08 at 11:05, Tom Lane wrote:
Steven Tower <tower@towerhome.cx> writes: > I am receiving the following error from Postgres 7.3.3 on Linux > Bogus attribute number 24 for vs_actfreighservices (a view). Hm, can you tell us how you got into this fix? That shouldn't happen AFAICS. As far as getting out of the problem is concerned, if you don't need the view you could just manually delete its pg_class row: as superuser do delete from pg_class where relname = 'vs_actfreighservices' (if you have multiple views named vs_actfreighservices in different schemas, more selectivity would be needed). That should leave you in a state where you can run pg_dump. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)