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