Received: from malur.postgresql.org ([217.196.149.56])
	by arkaria.postgresql.org with esmtp (Exim 4.72) (envelope-from
	<pgsql-performance-owner+M49051=pgsql-performance-ar@postgresql.org>)
	id 1TsKZs-00047w-2d for pgsql-performance@arkaria.postgresql.org;
	Mon, 07 Jan 2013 21:49:52 +0000
Received: from localhost ([127.0.0.1] helo=postgresql.org)
	by malur.postgresql.org with smtp (Exim 4.72) (envelope-from
	<pgsql-performance-owner+M49051=pgsql-performance-ar@postgresql.org>)
	id 1TsKZr-00055U-GJ for pgsql-performance@arkaria.postgresql.org;
	Mon, 07 Jan 2013 21:49:51 +0000
Received: from makus.postgresql.org ([98.129.198.125])
	by malur.postgresql.org with esmtp (Exim 4.72)
	(envelope-from <james@mansionfamily.plus.com>) id 1TsKZq-00054d-Bg
	for pgsql-performance@postgresql.org; Mon, 07 Jan 2013 21:49:50 +0000
Received: from avasout04.plus.net ([212.159.14.19])
	by makus.postgresql.org with esmtp (Exim 4.72)
	(envelope-from <james@mansionfamily.plus.com>) id 1TsKZo-00024N-SP
	for pgsql-performance@postgresql.org; Mon, 07 Jan 2013 21:49:49 +0000
Received: from server.barnhouse ([87.112.181.154]) by avasout04 with smtp
	id l9pk1k0073LGb0f019pmwS; Mon, 07 Jan 2013 21:49:46 +0000
X-CM-Score: 0.00
X-CNFS-Analysis: v=2.0 cv=XeZXOvF5 c=1 sm=1 a=6uqJNDenEZdphDPviEdeEQ==:17
	a=URPhxF5dMbEA:10 a=ihvODaAuJD4A:10 a=8nJEP1OIZ-IA:10 a=EBOSESyhAAAA:8
	a=jHKc3daqyJsA:10 a=s9LO-qrYOVtMFz4G45IA:9 a=wPNLvfGTeEIA:10
	a=ar2RNRryUg4qZzRb:21 a=FvrzmAj54t3fcxJj:21
	a=6uqJNDenEZdphDPviEdeEQ==:117
Received: from [192.168.0.96] (workstation.barnhouse [192.168.0.96])
	by server.barnhouse (Postfix) with ESMTP id 12CF96804D3
	for <pgsql-performance@postgresql.org>;
	Mon,  7 Jan 2013 21:52:57 +0000 (GMT)
Message-ID: <50EB42F6.6080108@mansionfamily.plus.com>
Date: Mon, 07 Jan 2013 21:49:42 +0000
From: james <james@mansionfamily.plus.com>
Reply-To: james@mansionfamily.plus.com
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64;
	rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: pgsql-performance@postgresql.org
Subject: Forcing WAL flush
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pg-Spam-Score: -1.2 (-)
List-Archive: <http://archives.postgresql.org/pgsql-performance>
List-Help: <mailto:majordomo@postgresql.org?body=help>
List-ID: <pgsql-performance.postgresql.org>
List-Owner: <mailto:pgsql-performance-owner@postgresql.org>
List-Post: <mailto:pgsql-performance@postgresql.org>
List-Subscribe: <mailto:majordomo@postgresql.org?body=sub%20pgsql-performance>
List-Unsubscribe: 
 <mailto:majordomo@postgresql.org?body=unsub%20pgsql-performance>
X-Mailing-List: pgsql-performance
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

Is there a way to force a WAL flush so that async commits (from other 
connections) are flushed, short of actually updating a sacrificial row?

Would be nice to do it without generating anything extra, even if it is 
something that causes IO in the checkpoint.

Am I right to think that an empty transaction won't do it, and nor will 
a transaction that is just a NOTIFY?


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance