I wrote: > The odds seem pretty good that the "corrupt compressed data" message > has the same origin at bottom, although the lack of any obvious data > to be compressed in this table is confusing. Maybe you could get that > from trying to copy over a garbage value of that one varchar column, > though. Nah, that's overthinking the problem. Just before the previously identified crash point, we have td = DatumGetHeapTupleHeader(datum); That's a pg_detoast_datum call underneath the macro. So if you assume that the tuple-datum pointer is pointing at garbage, you can get all three of the observed symptoms very easily, depending on what the garbage passing for its length word happens to look like. So I'm pretty sure that what we're dealing with is a case of the plan freeing a transient tuple datum sooner than it should. But the toy case I tried here didn't fail, so evidently I'm not close enough to the plan you're actually using. Still need to see that EXPLAIN output. It'd be helpful also to know what nondefault configuration settings you're using, especially work_mem and planner-related settings. Also, do you have an idea of how many rows might've matched the WHERE conditions? regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
