Subject: Re: Small Bug in GetConflictingVirtualXIDs
From: Simon Riggs <simon@2ndQuadrant.com>
To: Andres Freund <af@cybertec.de>
Cc: pgsql-hackers@postgresql.org, Tom Lane <tgl@sss.pgh.pa.us>,
	Alvaro Herrera <alvherre@commandprompt.com>
In-Reply-To: <200912220319.10264.af@cybertec.de>
References: <200912210402.37850.andres@anarazel.de>
	<15331.1261409887@sss.pgh.pa.us> <1261410532.17644.3336.camel@ebony>
	<200912220319.10264.af@cybertec.de>
Content-Type: text/plain
Date: Tue, 22 Dec 2009 10:42:30 +0000
Message-Id: <1261478551.7442.4332.camel@ebony>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

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.

> 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?

I don't see any mileage in making Startup process wait for an idle
session, so no real reason to wait for others either.

-- 
 Simon Riggs           www.2ndQuadrant.com