Received: from maia.hub.org (unknown [200.46.204.183])
	by mail.postgresql.org (Postfix) with ESMTP id 07EFE63326A
	for <pgsql-hackers-postgresql.org@mail.postgresql.org>;
	Mon, 21 Dec 2009 12:14:24 -0400 (AST)
Received: from mail.postgresql.org ([200.46.204.86])
	by maia.hub.org (mx1.hub.org [200.46.204.183]) (amavisd-maia,
	port 10024) with ESMTP id 22585-03
	for <pgsql-hackers-postgresql.org@mail.postgresql.org>;
	Mon, 21 Dec 2009 16:14:16 +0000 (UTC)
X-Greylist: delayed 00:09:13.813079 by SQLgrey-1.7.6
Received: from mail.anarazel.de (mail.anarazel.de [217.115.131.40])
	by mail.postgresql.org (Postfix) with ESMTP id 85FF663324C
	for <pgsql-hackers@postgresql.org>;
	Mon, 21 Dec 2009 12:14:16 -0400 (AST)
Received: from alap2.localnet (p549F5E2B.dip.t-dialin.net [84.159.94.43])
	by mail.anarazel.de (Postfix) with ESMTPSA id F09DE448004;
	Mon, 21 Dec 2009 17:04:59 +0100 (CET)
From: Andres Freund <af@cybertec.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Subject: Re: Small Bug in GetConflictingVirtualXIDs
Date: Mon, 21 Dec 2009 17:04:58 +0100
User-Agent: KMail/1.13.0 (Linux/2.6.32-andres-00908-g6ec22f9; KDE/4.3.80;
	x86_64; ; )
Cc: Alvaro Herrera <alvherre@commandprompt.com>, pgsql-hackers@postgresql.org,
	Simon Riggs <simon@2ndquadrant.com>
References: <200912210402.37850.andres@anarazel.de>
	<20091221152534.GB3913@alvh.no-ip.org>
	<15331.1261409887@sss.pgh.pa.us>
In-Reply-To: <15331.1261409887@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <200912211704.59321.af@cybertec.de>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=-2.599 tagged_above=-10 required=5
	tests=BAYES_00=-2.599
X-Spam-Level: 
X-Archive-Number: 200912/1868
X-Sequence-Number: 152571

On Monday 21 December 2009 16:38:07 Tom Lane wrote:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
> > Andres Freund wrote:
> >> The logic behind this seems fine except in the case of dropping a
> >> database. There you very well might have a open connection without an
> >> open snapshot.
> > Perhaps the simplest fix is to ensure that drop database gets a snapshot?
> I confess to not having followed the thread closely, but why is DROP
> DATABASE special in this regard?  Wouldn't we soon find ourselves
> needing every utility command to take a snapshot?
Because most other "entities" are locked when you access them. So on the 
standby the AccessExlusive (generated on the master) will conflict with 
whatever lock you currently have on that entity (on the slave).
There are no locks for an idle session though.

Andres