Received: from localhost (unknown [200.46.208.211])
	by mail.postgresql.org (Postfix) with ESMTP id 2F0D7632D2A
	for <pgsql-hackers-postgresql.org@mail.postgresql.org>;
	Tue, 22 Dec 2009 14:03:36 -0400 (AST)
Received: from mail.postgresql.org ([200.46.204.86])
	by localhost (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024)
	with ESMTP id 86920-04
	for <pgsql-hackers-postgresql.org@mail.postgresql.org>;
	Tue, 22 Dec 2009 18:03:23 +0000 (UTC)
X-Greylist: from auto-whitelisted 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 D54546323CA
	for <pgsql-hackers@postgresql.org>;
	Tue, 22 Dec 2009 14:03:24 -0400 (AST)
Received: from alap2.localnet (p549F2F26.dip.t-dialin.net [84.159.47.38])
	by mail.anarazel.de (Postfix) with ESMTPSA id 774B6448006;
	Tue, 22 Dec 2009 19:03:21 +0100 (CET)
From: Andres Freund <af@cybertec.de>
To: pgsql-hackers@postgresql.org
Subject: Re: Small Bug in GetConflictingVirtualXIDs
Date: Tue, 22 Dec 2009 19:03:20 +0100
User-Agent: KMail/1.13.0 (Linux/2.6.32-andres-00908-g6ec22f9; KDE/4.3.80;
	x86_64; ; )
Cc: Simon Riggs <simon@2ndquadrant.com>, Tom Lane <tgl@sss.pgh.pa.us>,
	Alvaro Herrera <alvherre@commandprompt.com>
References: <200912210402.37850.andres@anarazel.de>
	<200912220319.10264.af@cybertec.de>
	<1261478551.7442.4332.camel@ebony>
In-Reply-To: <1261478551.7442.4332.camel@ebony>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <200912221903.20624.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/1952
X-Sequence-Number: 152655

On Tuesday 22 December 2009 11:42:30 Simon Riggs wrote:
> On Tue, 2009-12-22 at 03:19 +0100, Andres Freund wrote:
> > On Monday 21 December 2009 16:48:52 Simon Riggs wrote:
> > > Giving the drop database a snapshot is not the answer. I expect Andres
> > > to be able to fix this with a simple patch that would not effect the
> > > case of normal running.
> >
> > Actually its less simply than I had thought at first - I don't think the
> > code ever handled that correctly.
> > I might be wrong there, my knowledge of the involved code is a bit
> > sparse... The whole conflict resolution builds on the concept of waiting
> > for an VXid, but an idle backend does not have a valid vxid. Thats
> > correct, right?
> 
> Yes, that's correct. I'll take this one back then.
So youre writing a fix or shall I?

Andres