Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229]) by mail.postgresql.org (Postfix) with ESMTP id 8733F23D694 for ; Mon, 23 Jul 2012 10:59:14 -0300 (ADT) Received: from mail-pb0-f46.google.com ([209.85.160.46]) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1StJAE-0004Wa-7P for pgsql-hackers@postgresql.org; Mon, 23 Jul 2012 13:59:13 +0000 Received: by pbbrp8 with SMTP id rp8so10928264pbb.19 for ; Mon, 23 Jul 2012 06:58:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=GKZCT9EYDtpk+C+clde4Js8R0Dd7CUqGQ3pDcixqlMI=; b=L83P2yxw5/zGE4OXe748Omjwue8fOK5SzjrIiGFe9FMZ0dg7ZjGHJtHe7xf1wUA2Qj USG4fL+QRv82aSZOz086CyN2+R2CeK7Q7VuURUtuVzaBaQRJqhbu8t6hHZDQMlRgnx4P 7EUMLE8+Riu3it60CwhhcrrJW40VdZZdURQTRbWmUuEYc9hMPfiQF6TPa/96doIKVY0f goKJgTWl/XmsHGDOF3LJP74PxML3MgYQhUykKpFpV2W6Vq4XjxXpWoxSWA3oTtUBhdph yMmhfbMCVnOrpI0L5m5LLykVD3uEy0HaLZ77aS+S91Ny+29io+SaVd/Q5raSedSGVNNq tMtA== Received: by 10.68.218.103 with SMTP id pf7mr35744379pbc.67.1343051936149; Mon, 23 Jul 2012 06:58:56 -0700 (PDT) Received: from ayaki.localdomain (124-169-186-146.dyn.iinet.net.au. [124.169.186.146]) by mx.google.com with ESMTPS id rd7sm10018471pbc.70.2012.07.23.06.58.51 (version=SSLv3 cipher=OTHER); Mon, 23 Jul 2012 06:58:55 -0700 (PDT) Message-ID: <500D5897.705@ringerc.id.au> Date: Mon, 23 Jul 2012 21:58:47 +0800 From: Craig Ringer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120717 Thunderbird/14.0 MIME-Version: 1.0 To: Andrew Dunstan CC: David Fetter , Tom Lane , Robert Haas , Jeff Janes , pgsql-hackers , Daniel Farina , =?ISO-8859-1?Q?=22Harold_A=2E_Gim?= =?ISO-8859-1?Q?=E9nez=22?= Subject: Re: Checkpointer split has broken things dramatically (was Re: DELETE vs TRUNCATE explanation) References: <9603.1342454919@sss.pgh.pa.us> <11952.1342456591@sss.pgh.pa.us> <13011.1342457859@sss.pgh.pa.us> <15955.1342466333@sss.pgh.pa.us> <9247.1342565810@sss.pgh.pa.us> <20120723043733.GA13020@fetter.org> <500D439C.50608@dunslane.net> <500D4BEE.7010205@ringerc.id.au> <500D55E4.40002@dunslane.net> In-Reply-To: <500D55E4.40002@dunslane.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQl5pPoQOku9oXH7bR1QK5//Cw58013d/zIIyc0cGeCygizdRWT0flmbA0ZHN4ZYi/o1Xcb0 X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201207/927 X-Sequence-Number: 211610 On 07/23/2012 09:47 PM, Andrew Dunstan wrote: > > On 07/23/2012 09:04 AM, Craig Ringer wrote: >> On 07/23/2012 08:29 PM, Andrew Dunstan wrote: >> >>> I'm not sure how you automate testing a pull-the-plug scenario. >> >> fire up kvm or qemu instances, then kill 'em. >> >> > > Yeah, maybe. Knowing just when to kill them might be an interesting > question. > > I'm also unsure how much nice cleanup the host supervisor does in such > cases. VMs are wonderful things, but they aren't always the answer. > I'm not saying they aren't here, just wondering. I've done some testing with this, and what it boils down to is that any data that made it to the virtual disk is persistent after a VM kill. Anything in dirty buffers on the VM guest is lost. It's a very close match for real hardware. I haven't tried to examine the details of the handling of virtualised disk hardware write caches, but disks should be in write-through mode anyway. A `kill -9` will clear 'em for sure, anyway, as the guest has no chance to do any cleanup. One of the great things about kvm and qemu for this sort of testing is that it's just another program. There's very little magic, and it's quite easy to test and trace. I have a qemu/kvm test harness I've been using for another project that I need to update and clean up as it'd be handy for this. It's just a matter of making the time, as it's been a busy few days. -- Craig Ringer