Обсуждение: row is too big during cluster
Hello, I have a problem during CLUSTER procedure. At some point I get row is too big: size 103400, maximum size 8136 error. How can I determine which row is too big? -- Łukasz Brodziak "Do you bury me when I'm gone Do you teach me while I'm here Just as soon I belong Then it's time I disappear"
Lukasz Brodziak <lukasz.brodziak@gmail.com> wrote: > I have a problem during CLUSTER procedure. At some point I get row > is too big: size 103400, maximum size 8136 error. How can I > determine which row is too big? What version of PostgreSQL? What does the table definition look like? Did anything unusual happen on this server or to this database? Is the problem repeatable and consistent? A copy/paste of the exact error message(s) would be better. Be sure to check the PostgreSQL log for any clues beyond what you see in the application http://wiki.postgresql.org/wiki/Guide_to_reporting_problems -Kevin
Hello, PostgreSQL version: 8.2.4 Exact message: 2011-07-08 09:50:29 ERROR: row is too big: size 103400, maximum size 8136 Table definition: CREATE TABLE Insurance_cards ( card_no bigint NOT NULL, card_dupl_no smallint NOT NULL, card_type character varying(1) NOT NULL, cancel_reason character varying(1) NOT NULL, cancel_date date NOT NULL, delete_date date, CONSTRAINT pk_Insurance_cards PRIMARY KEY (card_no , card_dupl_no) ) WITH (OIDS=FALSE); ALTER TABLE uniew_karty_ub OWNER TO "SYSADM"; The problem is repeatable and consistant within this singular database. 2011/7/8 Kevin Grittner <Kevin.Grittner@wicourts.gov>: > Lukasz Brodziak <lukasz.brodziak@gmail.com> wrote: > >> I have a problem during CLUSTER procedure. At some point I get row >> is too big: size 103400, maximum size 8136 error. How can I >> determine which row is too big? > > What version of PostgreSQL? What does the table definition look > like? Did anything unusual happen on this server or to this > database? Is the problem repeatable and consistent? > > A copy/paste of the exact error message(s) would be better. Be sure > to check the PostgreSQL log for any clues beyond what you see in the > application > > http://wiki.postgresql.org/wiki/Guide_to_reporting_problems > > -Kevin > -- Łukasz Brodziak "Do you bury me when I'm gone Do you teach me while I'm here Just as soon I belong Then it's time I disappear"
Lukasz Brodziak <lukasz.brodziak@gmail.com> wrote: > PostgreSQL version: 8.2.4 Major version 8.2 will be five years old in December, at which point it will be considered unsupported. It would be wise to have a plan to upgrade by then. http://wiki.postgresql.org/wiki/PostgreSQL_Release_Support_Policy The current bug-fix level of 8.2 is 8.2.21. You are missing over four years of bug and security fixes. It's not unlikely that you would not be seeing this if you had kept up on minor (bug fix) releases. Whether an upgrade will make the problem go away without some sort of fix for what's now in the table is less certain. http://www.postgresql.org/support/versioning You can browse the fixes here: http://www.postgresql.org/docs/8.2/static/release.html > Exact message: 2011-07-08 09:50:29 ERROR: row is too big: size > 103400, maximum size 8136 > Table definition: > CREATE TABLE Insurance_cards > ( > card_no bigint NOT NULL, > card_dupl_no smallint NOT NULL, > card_type character varying(1) NOT NULL, > cancel_reason character varying(1) NOT NULL, > cancel_date date NOT NULL, > delete_date date, > CONSTRAINT pk_Insurance_cards > PRIMARY KEY (card_no, card_dupl_no) > ) > WITH (OIDS=FALSE); Well, there's no way you should be seeing wide rows on that table. > The problem is repeatable and consistant within this singular > database. Do you get the problem on SELECT count(*) FROM the table? How about CREATE TABLE x AS SELECT * FROM the table? You may be able to narrow down the affected row(s) by selecting ranges by primary key to see what works and what fails. I would also be wary of possible hardware issues on this box, but it's hard to point the finger in that direction with much certainty, given that you're running with such a large number of known bugs, without applying the fixes for them. -Kevin