Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229]) by mail.postgresql.org (Postfix) with ESMTP id 6CA7F37EB72 for ; Sun, 15 Jul 2012 21:41:04 -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 1SqZMw-0002Ng-TW for pgsql-hackers@postgresql.org; Mon, 16 Jul 2012 00:41:03 +0000 Received: by pbbrp8 with SMTP id rp8so9119929pbb.19 for ; Sun, 15 Jul 2012 17:40:43 -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=3pLEhtyU+0BsJpVFImvPolRLhs4514E7NO8lLY6gsSs=; b=FhD7njVIylvHjld02XoRCaUv4JlzAsDqgORNHFu+p37qgbp/zMoYZDkXn+Jtwpiak2 jDpXeKMijIrapkHs8ML8o2LtmqFCnJdxMRQvEd9pxXxoIGeJw63L1XbaxXutONlqQuXM 64HWf2pcyj59i6X2iZR4/fdPq10MXzFxO1vD25RSKKhRuwm8Qi/AWYsOG963Y1gkEvWD MdKwWa0Gw2syrqNKzF+QvnWuuRdOQElF9BGm7ySIpstMJ9zlQANzVr+YFIZJzDYedFkT W/8AVsQwH82Jew0C/WI509AfyD+FLIKrOpaGGoagvXFMugM3sDArgcLdGg3WnGtjLetA J75Q== Received: by 10.68.201.7 with SMTP id jw7mr22409891pbc.60.1342399243276; Sun, 15 Jul 2012 17:40:43 -0700 (PDT) Received: from ayaki.localdomain ([114.75.86.47]) by mx.google.com with ESMTPS id qp9sm10731904pbc.9.2012.07.15.17.40.39 (version=SSLv3 cipher=OTHER); Sun, 15 Jul 2012 17:40:42 -0700 (PDT) Message-ID: <50035EE3.8030607@ringerc.id.au> Date: Mon, 16 Jul 2012 08:22:59 +0800 From: Craig Ringer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0 MIME-Version: 1.0 To: Tom Lane CC: Jeff Janes , pgsql-hackers , Daniel Farina , =?ISO-8859-1?Q?=22Harold_A=2E_Gim?= =?ISO-8859-1?Q?=E9nez=22?= Subject: Re: [PERFORM] DELETE vs TRUNCATE explanation References: <4FFCCAC4.4030503@ringerc.id.au> <23853.1342015548@sss.pgh.pa.us> <32078D4B40DD40ECB739D0ECD7D95996@gmail.com> <19949.1342376967@sss.pgh.pa.us> In-Reply-To: <19949.1342376967@sss.pgh.pa.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmd5luHaNReKt8IS0mA0t2EaLpSz5dtlX1ZMEzPyyEJyJw3s1XkFJ+QM2PheBtBIOtWshWe X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201207/688 X-Sequence-Number: 211371 On 07/16/2012 02:29 AM, Tom Lane wrote: > Yeah, you have a point there. It's not real clear that switching fsync > from off to on is an operation that we can make any guarantees about, > short of executing something like the code recently added to initdb > to force-sync the entire PGDATA tree. There's one way that doesn't have any housekeeping cost to Pg. It's pretty bad manners if there's anybody other than Pg on the system though: sync() Let the OS do the housekeeping. It's possible to do something similar on Windows, in that there are utilities for the purpose: http://technet.microsoft.com/en-us/sysinternals/bb897438.aspx This probably uses: http://msdn.microsoft.com/en-us/library/s9xk9ehd%28VS.71%29.aspx from COMMODE.OBJ (unfortunate name), which has existed since win98. > Perhaps we should change fsync > to be PGC_POSTMASTER (ie frozen at postmaster start), and then we could > skip forwarding fsync requests when it's off? Personally, I didn't even know it was runtime switchable. fsync=off is much less necessary with async commits, group commit via commit delay, WAL improvements, etc. To me it's mostly of utility when testing, particularly on SSDs. I don't see a DB restart requirement as a big issue. It'd be interesting to see what -general has to say, if there are people depending on this. If it's necessary to retain the ability to runtime switch it, making it a somewhat rude sync() in exchange for boosted performance the rest of the time may well be worthwhile anyway. It'd be interesting to see. All this talk of synchronisation is making me really frustrated that there seems to be very poor support in OSes for syncing a set of files in a single pass, potentially saving a lot of time and thrashing. A way to relax the ordering guarantee from "Files are synced in the order fsync() is called on each" to "files are all synced when this call completes" would be great. I've been running into this issue in some non-Pg-related work and it's been bugging me. -- Craig Ringer