On Sun, 2009-12-27 at 20:11 +0100, Andres Freund wrote:
On Tuesday 22 December 2009 11:42:30 Simon Riggs wrote:
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
On Sun, 2009-12-27 at 20:11 +0100, Andres Freund wrote:
On Tuesday 22 December 2009 11:42:30 Simon Riggs wrote:
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
On Sun, 2009-12-27 at 20:11 +0100, Andres Freund wrote:
On Tuesday 22 December 2009 11:42:30 Simon Riggs wrote:
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
On Tuesday 22 December 2009 11:42:30 Simon Riggs wrote:
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
On Sunday 27 December 2009 21:04:43 Simon Riggs wrote:
On Sun, 2009-12-27 at 20:11 +0100, Andres Freund wrote:
On Tuesday 22 December 2009 11:42:30 Simon Riggs wrote:
On Tue, 2009-12-22 at 03:19 +0100, Andres Freund wrote:
On Monday 21 December 2009 16:48:52 Simon Riggs wrote:
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
On Tuesday 22 December 2009 11:42:30 Simon Riggs wrote:
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
On Mon, 2009-12-21 at 04:02 +0100, Andres Freund wrote:
The logic behind this seems fine except in the case of dropping a database.
There you very well might have a open connection without an open snapshot.
Yes, you're right, thanks for the report.
I re-arranged the logic there recently to
Andres Freund wrote:
The logic behind this seems fine except in the case of dropping a database.
There you very well might have a open connection without an open snapshot.
Perhaps the simplest fix is to ensure that drop database gets a snapshot?
--
Alvaro Herrera
Alvaro Herrera alvhe...@commandprompt.com writes:
Andres Freund wrote:
The logic behind this seems fine except in the case of dropping a database.
There you very well might have a open connection without an open snapshot.
Perhaps the simplest fix is to ensure that drop database gets a
On Mon, 2009-12-21 at 10:38 -0500, Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Andres Freund wrote:
The logic behind this seems fine except in the case of dropping a
database.
There you very well might have a open connection without an open snapshot.
Perhaps
On Monday 21 December 2009 16:38:07 Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Andres Freund wrote:
The logic behind this seems fine except in the case of dropping a
database. There you very well might have a open connection without an
open snapshot.
Perhaps the
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
Hi Simon, Hi all,
HS currently does the following in GetConflictingVirtualXIDs
TransactionId pxmin = proc-xmin;
/*
* We ignore an invalid pxmin because this means that backend
* has no snapshot and cannot get another one while we hold exclusive lock.
*/
if (TransactionIdIsValid(pxmin)
14 matches
Mail list logo
