Hi
In the process of re-verifying my serializable lock consistency patch, I ran
the fk_concurrency testsuite against *unpatched* HEAD for comparison.
My build of HEAD had asserts enabled, and I promptly triggered
Assert(!(tp.t_data-t_infomask HEAP_XMAX_INVALID))
in heap_delete().
The seems
Florian Pflug f...@phlo.org writes:
In the process of re-verifying my serializable lock consistency patch, I ran
the fk_concurrency testsuite against *unpatched* HEAD for comparison.
My build of HEAD had asserts enabled, and I promptly triggered
Assert(!(tp.t_data-t_infomask
On Dec14, 2010, at 21:18 , Tom Lane wrote:
Florian Pflug f...@phlo.org writes:
In the process of re-verifying my serializable lock consistency patch, I ran
the fk_concurrency testsuite against *unpatched* HEAD for comparison.
My build of HEAD had asserts enabled, and I promptly triggered
Florian Pflug f...@phlo.org writes:
Could you explain what seems to be wrong with my patch?
I'm unconvinced that this is the proper response to whatever the problem
is; and if it is the right response, it seems to still need a good bit
more work. You didn't even update the functions' header
On Dec14, 2010, at 21:52 , Tom Lane wrote:
Florian Pflug f...@phlo.org writes:
Could you explain what seems to be wrong with my patch?
I'm unconvinced that this is the proper response to whatever the problem
is;
Well, you didn't comment on the part of my previous e-mail that *did*
explain
On Dec14, 2010, at 22:34 , Florian Pflug wrote:
For non-assert-enabled builds, the only effect of the patch is thus to
consistently return InvalidTransactionId if the crosscheck snapshot turns
HeapTupleMayBeUpdated into HeapTupleUpdated. Which certainly seems to be
an improvement over
