Re: Nondestructive cluster, equivalent SQL?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Joshua b(dot) Jore" <josh(at)greentechnologist(dot)org>
Cc: pgsql-novice(at)postgresql(dot)org
Subject: Re: Nondestructive cluster, equivalent SQL?
Date: 2002-05-24 22:49:49
Message-ID: 21883.1022280589@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-novice

"Joshua b. Jore" <josh(at)greentechnologist(dot)org> writes:
> So wouldn't it work just as well and avoid the problems by executing:

> CREATE TABLE cluster_SoSIDs AS SELECT * FROM SoSIDs ORDER BY SoSID;
> TRUNCATE SoSIDs;
> INSERT INTO SoSIDs SELECT * FROM cluster_SoSIDs ORDER BY SoSID;

<<itch>> ... if we allow that, we probably shouldn't. Since TRUNCATE
can't be rolled back, it's not supposed to be allowed inside a
transaction block.

Think about what happens if you get an error or a system crash while
that INSERT is running. The INSERT rolls back; the CREATE TABLE
rolls back; the TRUNCATE does not. You just lost all your data.

If you can assume no one else is modifying the table then you could
defend against this by creating the holding-tank table in a separate
transaction before you do the TRUNCATE/INSERT. Then you'd still have
your data in event of a crash, though you'd probably need a manual
recovery procedure to move it back where you want it. But it's not
much of a general-purpose solution I'm afraid.

regards, tom lane

In response to

Responses

Browse pgsql-novice by date

  From Date Subject
Next Message Tom Lane 2002-05-24 23:45:49 Re: Nondestructive cluster, equivalent SQL?
Previous Message Joshua b. Jore 2002-05-24 22:43:56 Nondestructive cluster, equivalent SQL?