On Mon, Feb 03, 2014 at 03:33:13PM +0100, Godefroid Chapelle wrote:
> Le 03/02/14 15:12, Marius Gedminas a écrit :
> >Could you tell us why that test depends on Acquisition? Is it possible
> >to replicate the bug using pure Python code?
>
> I have not been able to replicate the bug with pure Pyth
Le 03/02/14 15:12, Marius Gedminas a écrit :
Could you tell us why that test depends on Acquisition? Is it possible
to replicate the bug using pure Python code?
Marius Gedminas
I have not been able to replicate the bug with pure Python code. Reason
why it took me so much time.
IIRC, the is
On Mon, Feb 03, 2014 at 02:50:42PM +0100, Godefroid Chapelle wrote:
> It needed time and obstinacy to find how to write a test that
> triggers the same POSKeyError during commit as triggered by some
> Plone 3 to 4 migrations.
>
> For more details about the error, see
> http://rpatterson.net/blog/p
Hi all,
It needed time and obstinacy to find how to write a test that triggers
the same POSKeyError during commit as triggered by some Plone 3 to 4
migrations.
For more details about the error, see
http://rpatterson.net/blog/poskeyerror-during-commit
The test is now pushed to the 3.10 bran
Le 17/09/13 10:44, Godefroid Chapelle a écrit :
Hi,
Plone 3 to 4 migration occasionally triggers a POSKeyError during
transaction commit. See
http://rpatterson.net/blog/poskeyerror-during-commit
I encountered the issue yesterday.
I committed a test and a fix in branch 3.10.
https://github.com
Hi,
Plone 3 to 4 migration occasionally triggers a POSKeyError during
transaction commit. See http://rpatterson.net/blog/poskeyerror-during-commit
I encountered the issue yesterday.
I committed a test and a fix in branch 3.10.
https://github.com/zopefoundation/ZODB/commit/6457bcfd07b3b77f240
On Fri, Aug 3, 2012 at 11:56 PM, Maurits van Rees
wrote:
> Earlier this week I encountered a PosKeyError. This is in a Plone site with
> RelStorage (postgres). The traceback pointed to a DateRangeIndex. In the
> end I solved it by removing this index (the effectiveRange index) and
> recreating
Hi,
Earlier this week I encountered a PosKeyError. This is in a Plone site
with RelStorage (postgres). The traceback pointed to a DateRangeIndex.
In the end I solved it by removing this index (the effectiveRange
index) and recreating and indexing it.
So: problem solved, but I wonder if it
Shane,
I think the pre-pack will take that long (we have never waited long enough for
a gc pack to complete the first stages). We have db replication and I'll peel
of one of the slaves to do the pack... so it's not the end of the world (unless
the db is hosed :) )
-EAD
On Jun 22, 2011, at
On 06/22/2011 04:37 PM, Shane Hathaway wrote:
> On 06/22/2011 04:27 PM, Erik Dahl wrote:
>> Ugh. Ok I'll see what we get. So I'm clear we are looking for references
>> to the object/tid pairs that don't exist. Pack will take at lest 2 days to
>> run. :(
>
> Well, just pre-pack shouldn't take t
On 06/22/2011 04:27 PM, Erik Dahl wrote:
> Ugh. Ok I'll see what we get. So I'm clear we are looking for references to
> the object/tid pairs that don't exist. Pack will take at lest 2 days to run.
> :(
Well, just pre-pack shouldn't take that long (I hope).
Shane
Ugh. Ok I'll see what we get. So I'm clear we are looking for references to
the object/tid pairs that don't exist. Pack will take at lest 2 days to run. :(
-EAD
On Jun 22, 2011, at 5:08 PM, Shane Hathaway wrote:
> On 06/21/2011 07:18 AM, Erik Dahl wrote:
>> I'm using relstorage 1.4.2 durin
On 06/21/2011 07:18 AM, Erik Dahl wrote:
> I'm using relstorage 1.4.2 during a batch job I was running last night I got
> the following errors.
>
> 2011-06-21 07:55:02,664 WARNING relstorage: POSKeyError on oid 23916102: no
> tid found; Current transaction is 256466219826629358; Recent object tid
I'm using relstorage 1.4.2 during a batch job I was running last night I got
the following errors.
2011-06-21 07:55:02,664 WARNING relstorage: POSKeyError on oid 23916102: no tid
found; Current transaction is 256466219826629358; Recent object tids: []
2011-06-21 07:55:02,665 WARNING relstorage
Hi Chris,I am no ZODB expert. But I see a few thins that are wrong with the code. Others should be able to comment at length: - You cant just catch ConflictError and pass - I think you can catch a ReadConflictError and *retry* that is ok.
- But a ConflictError needs to be *retried* manually i
Hi,
This looks like a bug to me, but maybe I'm just doing something stupid
(possibly it's not allowed to deepcopy a Persistent object and then
re-sync the connection?). Try running several instances of the
following code in parallel (3 is enough for me here). Seems to be some
race condition; I qu
Dieter Maurer wrote:
I cannot reproduce easily the problem so I'd like to know
if there are suggestions in order to understand and
track down what's happening..
Forgetting "abort"s or passing persistent objects to different
threads may cause "POSKeyError"s (though there are probably more
poss
Thanks Chris,
Chris Withers wrote:
I cannot reproduce easily the problem so I'd like to know
if there are suggestions in order to understand and
track down what's happening..
Your best bet is to post the actual traceback here and explain the data
structures involved...
Chris
I'm trying
Paolo Linux wrote at 2005-11-17 10:23 +0100:
> ...
>I suspect that in some cases we do not manage Conflict
>Error (we retry for 3 times but then we give up...).
>Could this be connected with POSKeyErrors?
It should not. Because "giving up" should mean you abort the
transaction and your transaction
Paolo Linux wrote:
I suspect that in some cases we do not manage Conflict
Error (we retry for 3 times but then we give up...).
Could this be connected with POSKeyErrors?
Maybe, but probably not...
I cannot reproduce easily the problem so I'd like to know
if there are suggestions in order to u
Hi all,
we've developed an application developed using
ZODB 3.5.1. The load has recently grown up considerably
and we're starting getting POSKeyErrors...
We've never used undoing, so that cannot be the cause.
I suspect that in some cases we do not manage Conflict
Error (we retry for 3 times
21 matches
Mail list logo
