Thread: pg_dump aborts with triggers error
Hi Everyone!
My pg_dump is failing.PostgreSQL 8.3.7, compiled by gcc (unable to upgrade on this system)
CentOS release 5.9 32-bit
Command and output:
root@ryenguis ~# pg_dump -vt gtrk urr > smackfile
pg_dump: reading schemas
pg_dump: reading user-defined functions
pg_dump: reading user-defined types
pg_dump: reading procedural languages
pg_dump: reading user-defined aggregate functions
pg_dump: reading user-defined operators
pg_dump: reading user-defined operator classes
pg_dump: reading user-defined text search parsers
pg_dump: reading user-defined text search templates
pg_dump: reading user-defined text search dictionaries
pg_dump: reading user-defined text search configurations
pg_dump: reading user-defined operator families
pg_dump: reading user-defined conversions
pg_dump: reading user-defined tables
pg_dump: reading table inheritance information
pg_dump: reading rewrite rules
pg_dump: reading type casts
pg_dump: finding inheritance relationships
pg_dump: reading column info for interesting tables
pg_dump: finding the columns and types of table "gtrk"
pg_dump: finding default expressions of table "gtrk"
pg_dump: flagging inherited columns in subtables
pg_dump: reading indexes
pg_dump: reading indexes for table "gtrk"
pg_dump: reading constraints
pg_dump: reading foreign key constraints for table "gtrk"
pg_dump: reading triggers
pg_dump: reading triggers for table "gtrk"
pg_dump: expected -31896 triggers on table "gtrk" but found 0
pg_dump: *** aborted because of error
How do I fix the triggers error? A pg_dump works if I do an --exclude-table=gtrk
---
-Tim
Tim White <tim.white2005@gmail.com> writes: > My pg_dump is failing. > PostgreSQL 8.3.7, compiled by gcc (unable to upgrade on this system) I trust you're aware that this version is several years past its five-year support lifespan. Please consider upgrading soon. > pg_dump: reading triggers for table "gtrk" > pg_dump: expected -31896 triggers on table "gtrk" but found 0 Ouch. Don't ordinary queries/updates on this table fail with comparable complaints? What this evidently means is that pg_class.reltriggers contains -31896 in the row for gtrk, when it should contain 0 (or, if not that, surely something nonnegative, to wit the count of related entries in pg_trigger). I'd try "select * from pg_class where relname = 'gtrk'" and look to see if any of the other columns are obviously insane. If not, you might be able to skate by with manually UPDATE'ing that column to zero (as a superuser). But it's fairly uncommon for just one field in a table to randomly change to something else. The odds are that there's more corruption elsewhere, and that thought should scare you. BTW, the last release in the 8.3 series was 8.3.23. Whether or not you feel you can cope with updating to a new major-release series right now, continuing to run 8.3.7 with data that is valuable to you is simply irresponsible. Reasons why can be found in the release notes: http://www.postgresql.org/docs/8.3/static/release.html regards, tom lane