Received: from makus.postgresql.org (makus.postgresql.org [98.129.198.125]) by mail.postgresql.org (Postfix) with ESMTP id 2CF8555C5A4 for ; Mon, 16 Jul 2012 13:08:55 -0300 (ADT) Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1Sqnqw-0003HO-7J for pgsql-hackers@postgresql.org; Mon, 16 Jul 2012 16:08:54 +0000 Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.5/8.14.5) with ESMTP id q6GG8drG009604; Mon, 16 Jul 2012 12:08:39 -0400 (EDT) From: Tom Lane To: Robert Haas cc: Jeff Janes , pgsql-hackers , Daniel Farina , Craig Ringer , =?ISO-8859-1?Q?Harold_A=2E_Gim=E9nez?= Subject: Re: [PERFORM] DELETE vs TRUNCATE explanation In-reply-to: References: <4FFCCAC4.4030503@ringerc.id.au> <23853.1342015548@sss.pgh.pa.us> <32078D4B40DD40ECB739D0ECD7D95996@gmail.com> <19949.1342376967@sss.pgh.pa.us> Comments: In-reply-to Robert Haas message dated "Mon, 16 Jul 2012 11:58:59 -0400" Date: Mon, 16 Jul 2012 12:08:39 -0400 Message-ID: <9603.1342454919@sss.pgh.pa.us> X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201207/709 X-Sequence-Number: 211392 Robert Haas writes: > On Sun, Jul 15, 2012 at 2:29 PM, 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. 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? > I would argue that such a change adds no measure of safety, anyway. Well, yes it does, and the reason was explained further down in the thread: since we have no particular guarantees as to how quickly postmaster children will absorb postgresql.conf updates, there could be individual processes still running with fsync = off long after the user thinks he's turned it on. A forced restart solves that. I believe the reason for the current coding in the fsync queuing stuff is so that you only have to worry about how long it takes the checkpointer to notice the GUC change, and not any random backend that's running a forty-hour query. > But, at a broader level, I am not very excited about this > optimization. It seems to me that if this is hurting enough to be > noticeable, then it's hurting us when fsync=on as well, and we had > maybe think a little harder about how to cut down on the IPC overhead. Uh, that's exactly what's under discussion. Not sending useless fsync requests when fsync is off is just one part of it; a part that happens to be quite useful for some test scenarios, even if not so much for production. (IIRC, the original complainant in this thread was running fsync off.) regards, tom lane