From: Andres Freund <af@cybertec.de>
To: pgsql-hackers@postgresql.org
Subject: Re: Small Bug in GetConflictingVirtualXIDs
Date: Tue, 22 Dec 2009 03:19:09 +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>
	<15331.1261409887@sss.pgh.pa.us>
	<1261410532.17644.3336.camel@ebony>
In-Reply-To: <1261410532.17644.3336.camel@ebony>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <200912220319.10264.af@cybertec.de>

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?
Sure, the code should be modifyable to handle that code mostly transparently 
(simply ignoring a invalid localTransactionId when the database id is valid), 
but ...

I am inclined to just unconditionally kill the users of the database. Its not 
like that would be an issue in production. I cant see a case where its 
important to run a session to its end on a database which was dropped on the 
master.
Opinions on that?

Andres