Re: Small Bug in GetConflictingVirtualXIDs - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Small Bug in GetConflictingVirtualXIDs
Date
Msg-id 200912220319.10264.af@cybertec.de
Whole thread Raw
In response to Re: Small Bug in GetConflictingVirtualXIDs  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Small Bug in GetConflictingVirtualXIDs  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Small change of the HS document
Next
From: Fujii Masao
Date:
Subject: Re: Streaming replication and non-blocking I/O