Re: Small Bug in GetConflictingVirtualXIDs
Andres Freund <af@cybertec.de>
From: Andres Freund <af@cybertec.de>
To: pgsql-hackers@postgresql.org
Cc: Simon Riggs <simon@2ndquadrant.com>, Tom Lane <tgl@sss.pgh.pa.us>, Alvaro Herrera <alvherre@commandprompt.com>
Date: 2009-12-22T02:19:09Z
Lists: 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