diff --git a/doc/TODO.detail/drop b/doc/TODO.detail/drop index 24a4cfebe1edd78a39d1e916c9422843c4873dcd..43b72df9cd2dc614df7cc55c70b63b522e3ac58d 100644 --- a/doc/TODO.detail/drop +++ b/doc/TODO.detail/drop @@ -2,7 +2,7 @@ From pgsql-hackers-owner+M3040@hub.org Thu Jun 8 00:31:01 2000 Received: from renoir.op.net (root@renoir.op.net [207.29.195.4]) by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id AAA13157 for ; Thu, 8 Jun 2000 00:31:00 -0400 (EDT) -Received: from hub.org (root@hub.org [216.126.84.1]) by renoir.op.net (o1/$Revision: 1.5 $) with ESMTP id AAA01089 for ; Thu, 8 Jun 2000 00:17:19 -0400 (EDT) +Received: from hub.org (root@hub.org [216.126.84.1]) by renoir.op.net (o1/$Revision: 1.6 $) with ESMTP id AAA01089 for ; Thu, 8 Jun 2000 00:17:19 -0400 (EDT) Received: from hub.org (majordom@localhost [127.0.0.1]) by hub.org (8.10.1/8.10.1) with SMTP id e5846ib99782; Thu, 8 Jun 2000 00:06:44 -0400 (EDT) @@ -280,7 +280,7 @@ From Inoue@tpf.co.jp Sat Jun 10 01:01:01 2000 Received: from renoir.op.net (root@renoir.op.net [207.29.195.4]) by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id BAA10355 for ; Sat, 10 Jun 2000 01:01:00 -0400 (EDT) -Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34]) by renoir.op.net (o1/$Revision: 1.5 $) with ESMTP id AAA25467 for ; Sat, 10 Jun 2000 00:41:32 -0400 (EDT) +Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34]) by renoir.op.net (o1/$Revision: 1.6 $) with ESMTP id AAA25467 for ; Sat, 10 Jun 2000 00:41:32 -0400 (EDT) Received: from mcadnote1 (ppm110.noc.fukui.nsk.ne.jp [210.161.188.29] (may be forged)) by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP id NAA03125; Sat, 10 Jun 2000 13:40:40 +0900 @@ -411,7 +411,7 @@ From tgl@sss.pgh.pa.us Sat Jun 10 01:31:04 2000 Received: from renoir.op.net (root@renoir.op.net [207.29.195.4]) by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id BAA10922 for ; Sat, 10 Jun 2000 01:31:03 -0400 (EDT) -Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2]) by renoir.op.net (o1/$Revision: 1.5 $) with ESMTP id BAA27265 for ; Sat, 10 Jun 2000 01:16:07 -0400 (EDT) +Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2]) by renoir.op.net (o1/$Revision: 1.6 $) with ESMTP id BAA27265 for ; Sat, 10 Jun 2000 01:16:07 -0400 (EDT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id BAA06206; Sat, 10 Jun 2000 01:14:37 -0400 (EDT) @@ -457,7 +457,7 @@ From dhogaza@pacifier.com Sat Jun 10 09:30:59 2000 Received: from renoir.op.net (root@renoir.op.net [207.29.195.4]) by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id JAA25987 for ; Sat, 10 Jun 2000 09:30:58 -0400 (EDT) -Received: from smtp.pacifier.com (comet.pacifier.com [199.2.117.155]) by renoir.op.net (o1/$Revision: 1.5 $) with ESMTP id JAA18716 for ; Sat, 10 Jun 2000 09:15:08 -0400 (EDT) +Received: from smtp.pacifier.com (comet.pacifier.com [199.2.117.155]) by renoir.op.net (o1/$Revision: 1.6 $) with ESMTP id JAA18716 for ; Sat, 10 Jun 2000 09:15:08 -0400 (EDT) Received: from desktop (dsl-dhogaza.pacifier.net [207.202.226.68]) by smtp.pacifier.com (8.9.3/8.9.3pop) with SMTP id GAA15799; Sat, 10 Jun 2000 06:14:28 -0700 (PDT) @@ -509,7 +509,7 @@ From tgl@sss.pgh.pa.us Sun Jun 11 12:31:03 2000 Received: from renoir.op.net (root@renoir.op.net [207.29.195.4]) by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id MAA05771 for ; Sun, 11 Jun 2000 12:31:01 -0400 (EDT) -Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2]) by renoir.op.net (o1/$Revision: 1.5 $) with ESMTP id MAA19315 for ; Sun, 11 Jun 2000 12:24:06 -0400 (EDT) +Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2]) by renoir.op.net (o1/$Revision: 1.6 $) with ESMTP id MAA19315 for ; Sun, 11 Jun 2000 12:24:06 -0400 (EDT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id MAA09503; Sun, 11 Jun 2000 12:22:42 -0400 (EDT) @@ -1861,3 +1861,362 @@ I meant to say is that the differene is very small. regards, Hiroshi Inoue +From tgl@sss.pgh.pa.us Sat Apr 13 11:30:17 2002 +Return-path: +Received: from sss.pgh.pa.us (root@[192.204.191.242]) + by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g3DFUGS26218 + for ; Sat, 13 Apr 2002 11:30:16 -0400 (EDT) +Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) + by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g3DFTjF15655; + Sat, 13 Apr 2002 11:29:45 -0400 (EDT) +To: "Christopher Kings-Lynne" +cc: "Bruce Momjian" , + "Hiroshi Inoue" , pgsql-hackers@postgresql.org +Subject: Re: DROP COLUMN (was RFC: Restructuring pg_aggregate) +In-Reply-To: <001701c1e2b2$e7b10a40$0200a8c0@SOL> +References: <20020411233659.O69846-100000@houston.familyhealth.com.au> <1824.1018542155@sss.pgh.pa.us> <001701c1e2b2$e7b10a40$0200a8c0@SOL> +Comments: In-reply-to "Christopher Kings-Lynne" + message dated "Sat, 13 Apr 2002 14:17:34 +0800" +Date: Sat, 13 Apr 2002 11:29:45 -0400 +Message-ID: <15652.1018711785@sss.pgh.pa.us> +From: Tom Lane +Status: OR + +[ way past time to change the title of this thread ] + +"Christopher Kings-Lynne" writes: +> OK, sounds fair. However, is there a more aggressive way of reclaiming the +> space? The problem with updating all the rows to null for that column is +> that the on-disk size is doubled anyway, right? So, could a VACUUM FULL +> process do the nulling for us? Vacuum works outside of normal transaction +> constraints anyway...? + +No, VACUUM has the same transactional constraints as everyone else +(unless you'd like a crash during VACUUM to trash your table...) + +I do not think that we necessarily need to provide a special mechanism +for this at all. The docs for DROP COLUMN could simply explain that +the DROP itself doesn't reclaim the space, but that the space will be +reclaimed over time as extant rows are updated or deleted. If you want +to hurry the process along you could do + UPDATE table SET othercol = othercol + VACUUM FULL +to force all the rows to be updated and then reclaim space. But given +the peak-space-is-twice-as-much behavior, this is not obviously a win. +I'd sure object to an implementation that *forced* that approach on me, +whether during DROP itself or the next VACUUM. + +> Also, it seems to me that at some point we are forced to break client +> compatibility. Either we add attisdropped field to pg_attribute, or we use +> Hiroshi's (-1 * attnum - offset) idea. Both Tom and Hiroshi have good +> reasons for each of these - would it be possible for you guys to post with +> your reasons for and against both the techniques. + +Er, didn't we do that already? + + regards, tom lane + +From chriskl@familyhealth.com.au Sun Apr 14 01:06:31 2002 +Return-path: +Received: from mail.iinet.net.au (symphony-03.iinet.net.au [203.59.3.35]) + by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g3E56TS03274 + for ; Sun, 14 Apr 2002 01:06:30 -0400 (EDT) +Received: (qmail 20365 invoked by uid 666); 14 Apr 2002 05:06:31 -0000 +Received: from unknown (HELO SOL) (203.59.168.230) + by mail.iinet.net.au with SMTP; 14 Apr 2002 05:06:31 -0000 +Message-ID: <00c601c1e371$0e324670$0200a8c0@SOL> +From: "Christopher Kings-Lynne" +To: "Tom Lane" +cc: "Bruce Momjian" , + "Hiroshi Inoue" , +References: <20020411233659.O69846-100000@houston.familyhealth.com.au> <1824.1018542155@sss.pgh.pa.us> <001701c1e2b2$e7b10a40$0200a8c0@SOL> <15652.1018711785@sss.pgh.pa.us> +Subject: Re: DROP COLUMN (was RFC: Restructuring pg_aggregate) +Date: Sun, 14 Apr 2002 12:58:43 +0800 +MIME-Version: 1.0 +Content-Type: text/plain; + charset="iso-8859-1" +Content-Transfer-Encoding: 7bit +X-Priority: 3 +X-MSMail-Priority: Normal +X-Mailer: Microsoft Outlook Express 5.50.4522.1200 +X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 +Status: OR + +> No, VACUUM has the same transactional constraints as everyone else +> (unless you'd like a crash during VACUUM to trash your table...) + +Seriously, you can run VACUUM in a transaction and rollback the movement of +a tuple on disk? What do you mean by same transactional constraints? + +Chris + + +From pgsql-hackers-owner+M21278@postgresql.org Sat Apr 13 12:21:20 2002 +Return-path: +Received: from postgresql.org (postgresql.org [64.49.215.8]) + by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g3DGLKS29823 + for ; Sat, 13 Apr 2002 12:21:20 -0400 (EDT) +Received: from postgresql.org (postgresql.org [64.49.215.8]) + by postgresql.org (Postfix) with SMTP + id 9B4AF475CA6; Sat, 13 Apr 2002 12:21:12 -0400 (EDT) +Received: from sss.pgh.pa.us (unknown [192.204.191.242]) + by postgresql.org (Postfix) with ESMTP id 1ED76474E71 + for ; Sat, 13 Apr 2002 12:20:07 -0400 (EDT) +Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) + by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g3DGJeF15983; + Sat, 13 Apr 2002 12:19:40 -0400 (EDT) +To: Hannu Krosing +cc: Christopher Kings-Lynne , + Bruce Momjian , Hiroshi Inoue , + pgsql-hackers@postgresql.org +Subject: Re: [HACKERS] DROP COLUMN (was RFC: Restructuring pg_aggregate) +In-Reply-To: <1018716432.3360.9.camel@taru.tm.ee> +References: <20020411233659.O69846-100000@houston.familyhealth.com.au> <1824.1018542155@sss.pgh.pa.us> <001701c1e2b2$e7b10a40$0200a8c0@SOL> <15652.1018711785@sss.pgh.pa.us> <1018716432.3360.9.camel@taru.tm.ee> +Comments: In-reply-to Hannu Krosing + message dated "13 Apr 2002 18:47:07 +0200" +Date: Sat, 13 Apr 2002 12:19:40 -0400 +Message-ID: <15980.1018714780@sss.pgh.pa.us> +From: Tom Lane +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +Status: OR + +Hannu Krosing writes: +>> No, VACUUM has the same transactional constraints as everyone else +>> (unless you'd like a crash during VACUUM to trash your table...) + +> But can't it do the SET TO NULL thing if it knows that the transaction +> that dropped the column has committed. + +Hmm, you're thinking of allowing VACUUM to overwrite tuples in-place? +Strikes me as unsafe, but I'm not really sure. + +In any case it's not that easy. If the column is wide enough +that reclaiming its space is actually worth doing, then presumably +most of its entries are just TOAST links, and what has to be done is +not just rewrite the main tuple but mark the TOAST rows deleted. +This is not something that VACUUM does now; I'd be rather concerned +about the locking implications (especially for lightweight VACUUM). + + regards, tom lane + +---------------------------(end of broadcast)--------------------------- +TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org + +From pgsql-hackers-owner+M21277@postgresql.org Sat Apr 13 11:51:02 2002 +Return-path: +Received: from postgresql.org (postgresql.org [64.49.215.8]) + by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g3DFp1S28016 + for ; Sat, 13 Apr 2002 11:51:01 -0400 (EDT) +Received: from postgresql.org (postgresql.org [64.49.215.8]) + by postgresql.org (Postfix) with SMTP + id B76F5475D68; Sat, 13 Apr 2002 11:47:59 -0400 (EDT) +Received: from gw.itmeedia.ee (gw.itmeedia.ee [213.180.3.226]) + by postgresql.org (Postfix) with SMTP id 0635E475C6F + for ; Sat, 13 Apr 2002 11:47:01 -0400 (EDT) +Received: (qmail 12309 invoked from network); 13 Apr 2002 15:47:06 -0000 +Received: from taru.itmeedia.ee (HELO taru.tm.ee) (213.180.3.230) + by gw.itmeedia.ee with SMTP; 13 Apr 2002 15:47:06 -0000 +Subject: Re: [HACKERS] DROP COLUMN (was RFC: Restructuring pg_aggregate) +From: Hannu Krosing +To: Tom Lane +cc: Christopher Kings-Lynne , + Bruce Momjian , Hiroshi Inoue , + pgsql-hackers@postgresql.org +In-Reply-To: <15652.1018711785@sss.pgh.pa.us> +References: <20020411233659.O69846-100000@houston.familyhealth.com.au> + <1824.1018542155@sss.pgh.pa.us> <001701c1e2b2$e7b10a40$0200a8c0@SOL> + <15652.1018711785@sss.pgh.pa.us> +Content-Type: text/plain +Content-Transfer-Encoding: 7bit +X-Mailer: Ximian Evolution 1.0.3.99 +Date: 13 Apr 2002 18:47:07 +0200 +Message-ID: <1018716432.3360.9.camel@taru.tm.ee> +MIME-Version: 1.0 +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +Status: OR + +On Sat, 2002-04-13 at 17:29, Tom Lane wrote: +> [ way past time to change the title of this thread ] +> +> "Christopher Kings-Lynne" writes: +> > OK, sounds fair. However, is there a more aggressive way of reclaiming the +> > space? The problem with updating all the rows to null for that column is +> > that the on-disk size is doubled anyway, right? So, could a VACUUM FULL +> > process do the nulling for us? Vacuum works outside of normal transaction +> > constraints anyway...? +> +> No, VACUUM has the same transactional constraints as everyone else +> (unless you'd like a crash during VACUUM to trash your table...) + +But can't it do the SET TO NULL thing if it knows that the transaction +that dropped the column has committed. + +This could probably even be done in the light version of vacuum with a +special flag (VACUUM RECLAIM). + +Of course running this this makes sense only if the dropped column had +some significant amount of data . + +> I do not think that we necessarily need to provide a special mechanism +> for this at all. The docs for DROP COLUMN could simply explain that +> the DROP itself doesn't reclaim the space, but that the space will be +> reclaimed over time as extant rows are updated or deleted. If you want +> to hurry the process along you could do +> UPDATE table SET othercol = othercol +> VACUUM FULL + +If only we could do it in namageable chunks: + +FOR i IN 0 TO (size(table)/chunk) DO + UPDATE table SET othercol = othercol OFFSET i*chunk LIMIT chunk + VACUUM FULL; +END FOR; + +or even better - "VACUUM FULL OFFSET i*chunk LIMIT chunk" and then make +chunk == 1 :) + +-------------- +Hannu + + +---------------------------(end of broadcast)--------------------------- +TIP 2: you can get off all lists at once with the unregister command + (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) + +From pgsql-hackers-owner+M21292@postgresql.org Sun Apr 14 01:07:16 2002 +Return-path: +Received: from postgresql.org (postgresql.org [64.49.215.8]) + by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g3E57FS03403 + for ; Sun, 14 Apr 2002 01:07:15 -0400 (EDT) +Received: from postgresql.org (postgresql.org [64.49.215.8]) + by postgresql.org (Postfix) with SMTP + id 78A86475DD7; Sun, 14 Apr 2002 01:07:12 -0400 (EDT) +Received: from mail.iinet.net.au (symphony-03.iinet.net.au [203.59.3.35]) + by postgresql.org (Postfix) with SMTP id DA1D447593E + for ; Sun, 14 Apr 2002 01:06:32 -0400 (EDT) +Received: (qmail 20365 invoked by uid 666); 14 Apr 2002 05:06:31 -0000 +Received: from unknown (HELO SOL) (203.59.168.230) + by mail.iinet.net.au with SMTP; 14 Apr 2002 05:06:31 -0000 +Message-ID: <00c601c1e371$0e324670$0200a8c0@SOL> +From: "Christopher Kings-Lynne" +To: "Tom Lane" +cc: "Bruce Momjian" , + "Hiroshi Inoue" , +References: <20020411233659.O69846-100000@houston.familyhealth.com.au> <1824.1018542155@sss.pgh.pa.us> <001701c1e2b2$e7b10a40$0200a8c0@SOL> <15652.1018711785@sss.pgh.pa.us> +Subject: Re: [HACKERS] DROP COLUMN (was RFC: Restructuring pg_aggregate) +Date: Sun, 14 Apr 2002 12:58:43 +0800 +MIME-Version: 1.0 +Content-Type: text/plain; + charset="iso-8859-1" +Content-Transfer-Encoding: 7bit +X-Priority: 3 +X-MSMail-Priority: Normal +X-Mailer: Microsoft Outlook Express 5.50.4522.1200 +X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +Status: OR + +> No, VACUUM has the same transactional constraints as everyone else +> (unless you'd like a crash during VACUUM to trash your table...) + +Seriously, you can run VACUUM in a transaction and rollback the movement of +a tuple on disk? What do you mean by same transactional constraints? + +Chris + + +---------------------------(end of broadcast)--------------------------- +TIP 4: Don't 'kill -9' the postmaster + +From tgl@sss.pgh.pa.us Sun Apr 14 14:13:33 2002 +Return-path: +Received: from sss.pgh.pa.us (root@[192.204.191.242]) + by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g3EIDWS18224 + for ; Sun, 14 Apr 2002 14:13:32 -0400 (EDT) +Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) + by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g3EIDMF22681; + Sun, 14 Apr 2002 14:13:22 -0400 (EDT) +To: "Christopher Kings-Lynne" +cc: "Bruce Momjian" , + "Hiroshi Inoue" , pgsql-hackers@postgresql.org +Subject: Re: [HACKERS] DROP COLUMN (was RFC: Restructuring pg_aggregate) +In-Reply-To: <00c601c1e371$0e324670$0200a8c0@SOL> +References: <20020411233659.O69846-100000@houston.familyhealth.com.au> <1824.1018542155@sss.pgh.pa.us> <001701c1e2b2$e7b10a40$0200a8c0@SOL> <15652.1018711785@sss.pgh.pa.us> <00c601c1e371$0e324670$0200a8c0@SOL> +Comments: In-reply-to "Christopher Kings-Lynne" + message dated "Sun, 14 Apr 2002 12:58:43 +0800" +Date: Sun, 14 Apr 2002 14:13:21 -0400 +Message-ID: <22678.1018808001@sss.pgh.pa.us> +From: Tom Lane +Status: OR + +"Christopher Kings-Lynne" writes: +>> No, VACUUM has the same transactional constraints as everyone else +>> (unless you'd like a crash during VACUUM to trash your table...) + +> Seriously, you can run VACUUM in a transaction and rollback the movement of +> a tuple on disk? What do you mean by same transactional constraints? + +In VACUUM FULL, tuples moved to compact the table aren't good until you +commit. In this hypothetical column-drop-implementing VACUUM, I think +there'd need to be some similar rule --- otherwise it's not clear what +happens to TOASTED data if you crash partway through. (In particular, +if we tried overwriting main tuples in place as Hannu was suggesting, +we'd need a way of being certain the deletion of the corresponding TOAST +rows occurs *before* we overwrite the only reference to them.) + + regards, tom lane + +From pgsql-hackers-owner+M21305@postgresql.org Sun Apr 14 14:14:46 2002 +Return-path: +Received: from postgresql.org (postgresql.org [64.49.215.8]) + by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g3EIEkS18333 + for ; Sun, 14 Apr 2002 14:14:46 -0400 (EDT) +Received: from postgresql.org (postgresql.org [64.49.215.8]) + by postgresql.org (Postfix) with SMTP + id 8FA74475C4C; Sun, 14 Apr 2002 14:14:43 -0400 (EDT) +Received: from sss.pgh.pa.us (unknown [192.204.191.242]) + by postgresql.org (Postfix) with ESMTP id 8AC04475892 + for ; Sun, 14 Apr 2002 14:13:52 -0400 (EDT) +Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) + by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g3EIDMF22681; + Sun, 14 Apr 2002 14:13:22 -0400 (EDT) +To: "Christopher Kings-Lynne" +cc: "Bruce Momjian" , + "Hiroshi Inoue" , pgsql-hackers@postgresql.org +Subject: Re: [HACKERS] DROP COLUMN (was RFC: Restructuring pg_aggregate) +In-Reply-To: <00c601c1e371$0e324670$0200a8c0@SOL> +References: <20020411233659.O69846-100000@houston.familyhealth.com.au> <1824.1018542155@sss.pgh.pa.us> <001701c1e2b2$e7b10a40$0200a8c0@SOL> <15652.1018711785@sss.pgh.pa.us> <00c601c1e371$0e324670$0200a8c0@SOL> +Comments: In-reply-to "Christopher Kings-Lynne" + message dated "Sun, 14 Apr 2002 12:58:43 +0800" +Date: Sun, 14 Apr 2002 14:13:21 -0400 +Message-ID: <22678.1018808001@sss.pgh.pa.us> +From: Tom Lane +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +Status: OR + +"Christopher Kings-Lynne" writes: +>> No, VACUUM has the same transactional constraints as everyone else +>> (unless you'd like a crash during VACUUM to trash your table...) + +> Seriously, you can run VACUUM in a transaction and rollback the movement of +> a tuple on disk? What do you mean by same transactional constraints? + +In VACUUM FULL, tuples moved to compact the table aren't good until you +commit. In this hypothetical column-drop-implementing VACUUM, I think +there'd need to be some similar rule --- otherwise it's not clear what +happens to TOASTED data if you crash partway through. (In particular, +if we tried overwriting main tuples in place as Hannu was suggesting, +we'd need a way of being certain the deletion of the corresponding TOAST +rows occurs *before* we overwrite the only reference to them.) + + regards, tom lane + +---------------------------(end of broadcast)--------------------------- +TIP 5: Have you checked our extensive FAQ? + +http://www.postgresql.org/users-lounge/docs/faq.html +