Re: Small Bug in GetConflictingVirtualXIDs
От | Simon Riggs |
---|---|
Тема | Re: Small Bug in GetConflictingVirtualXIDs |
Дата | |
Msg-id | 1261478551.7442.4332.camel@ebony обсуждение исходный текст |
Ответ на | Re: Small Bug in GetConflictingVirtualXIDs (Andres Freund <af@cybertec.de>) |
Ответы |
Re: Small Bug in GetConflictingVirtualXIDs
Re: Small Bug in GetConflictingVirtualXIDs |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: