Re: Small Bug in GetConflictingVirtualXIDs

From: Andres Freund <af(at)cybertec(dot)de>
To: pgsql-hackers(at)postgresql(dot)org
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Subject: Re: Small Bug in GetConflictingVirtualXIDs
Date: 2009-12-22 02:19:09
Message-ID: 200912220319.10264.af@cybertec.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2009-12-22 02:25:27 Small change of the HS document
Previous Message David E. Wheeler 2009-12-21 22:49:59 Re: Segfault from PL/Perl Returning vstring