People,

Here's another:

Summary: TOAST error on frequently truncated tables
Version: 7.4.2
Severity: Abort
Platform: Red Hat 9.0
When running a script against a reporting database, I'm getting the following:

DBD::Pg::st execute failed: ERROR: expected both swapped tables to have TOAST
tables at sql_data_xfer.pl line 120, <STDIN> line 2.
Process Failed: from step SELECT count(*) FROM elbs_client;Process Failed:
from step SELECT count(*) FROM elbs_client;
1 at sql_data_xfer.pl line 120, <STDIN> line 2.

What's happening in the scipt is that it's checking for the presence of data
in load tables and truncating them if data is found. I'm not absolutely
certain whether it is the COUNT(*) query, or the TRUNCATE step which is
producing the above error; TRUNCATE would seem more reasonable given the
nature of the error.

I've searched the source code, and the only reference to the error I can find
is for CLUSTER, which is confusing because none of the tables involved are
clustered.

Is this related to the index problem fixed in 7.4.x?

--
Josh Berkus
Aglio Database Solutions
San Francisco

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Josh Berkus <josh (AT) agliodbs (DOT) com> writes:
Have you done more to this table than TRUNCATE it?

We recognized relatively recently that ALTER DROP COLUMN could drop the
last/only variable-width column, in which case there is no longer any
need for a TOAST table. The 8.0 code for CLUSTER/TRUNCATE copes with
this possibility but 7.4 doesn't.

I'm quite sure you couldn't get this error from anything except CLUSTER
or TRUNCATE in 7.4 though. Seems like your client-side code is in error
to be fingering a plain SELECT as the cause.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Tom,

Aha! Yes, the problem is that I dropped the last VARCHAR column, not in that
table but in one that came after it. Any workaround to fix?

Yeah, well, I can't get the client to install Exception module.

--
Josh Berkus
Aglio Database Solutions
San Francisco

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Josh Berkus <josh (AT) agliodbs (DOT) com> writes:
Easiest is to add back a useless varchar column ...

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Tom,

Can't do it, the column needed to be dropped in order to fix a problem with
the data transfer. Maybe re-create the table?

--
Josh Berkus
Aglio Database Solutions
San Francisco

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

Josh Berkus <josh (AT) agliodbs (DOT) com> writes:
Yeah, I think you're stuck with doing that.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Tom,

BTW, this is a pretty nasty error, although apparently infrequent give the
lack of list e-mails. Can we fix it for 7.4 series?

--
Josh Berkus
Aglio Database Solutions
San Francisco

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Possibly, but I'm not very excited about it --- it's certainly a corner
case. I'm not sure it's worth the risk of breaking something.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org