On Fri, Nov 04, 2011 at 09:04:02PM -0400, Tom Lane wrote: > that. And that they are the only rows that, in addition to the above > conditions, contain data fields wide enough to require out-of-line > toasting. checked lengths of the text/varchar columns in database. there are 16 such columns in the table. full report of lengths is in http://www.depesz.com/various/lengths.report.gz it was obtained using: select length( "first_text_column" ) as length_1, count(*) from etsy_v2.receipts group by 1 order by 1; and so on for every text column, and at the end I also made summary of sum-of-lengths. there is also: http://www.depesz.com/various/lengths2.report.gz which has the same summary, but only of the damaged rows. As you can see the length of columns is not really special - somewhere in the middle of all other rows. summarized length is also not special in any way. > These conditions together are enough to break the assumption in > toast_insert_or_update that the old and new tuples must have the same > value of t_hoff. But it can only happen when the source tuple is an > original on-disk tuple, which explains why only INSERT ... SELECT * > causes the problem, not any variants that require projection of a new > column set. When it does happen, toast_insert_or_update correctly > computes the required size of the new tuple ... but then it tells > heap_fill_tuple to fill the data part at offset olddata->t_hoff, which > is wrong (too small) and so the nulls bitmap that heap_fill_tuple > concurrently constructs will overwrite the first few data bytes. In > your example, the table contains 49 columns so the nulls bitmap requires > 7 bytes, just enough to overwrite the first 6 data bytes as observed. > (In fact, given the values we see being filled in, I can confidently say > that you have two added-since-creation null columns, no more, no less.) > > I can reproduce the problem with the attached test case (using the > regression database). With asserts enabled, the > Assert(new_len == olddata->t_hoff); > fails. With asserts off, corrupt data. How can I make the onek table for the test? is it standard table from something? > This is trivial to fix, now that we know there's a problem --- the > function is only using that assumption to save itself a couple lines > of code. Penny wise, pound foolish :-( Any chance of getting the fix in patch format so we could test it on this system? Best regards, depesz -- The best thing about modern society is how easy it is to avoid contact with it. http://depesz.com/ -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
