Magnus wrote:
> I ran the web application mentioned in Marti's original mail on a patched
> Postgres server. It looks like it is working correctly now, no more test
> failures.
Thanks for the confirmation. I pushed the fix, along with the presented
test case.
I chose to backpatch all the way
I ran the web application mentioned in Marti's original mail on a
patched Postgres server. It looks like it is working correctly now, no
more test failures.
Thanks
-Magnus
On 07.09.2016 21:49, Marko Tiikkaja wrote:
On 07/09/16 7:29 PM, Alvaro Herrera wrote:
Marko, does this fix your
On 07/09/16 7:29 PM, Alvaro Herrera wrote:
Marko, does this fix your reported problem too? Both the assertion and
the overall test case that causes it to fire?
The test case never realized anything was wrong, but the assertion is
gone. So yup, problem solved on this end, at least.
.m
Marti Raudsepp wrote:
> Hello list
>
> While testing an application with PostgreSQL 9.5, we experienced an issue
> involving aborted subtransactions and SELECT FOR UPDATE. In certain
> situations, a locking query doesn't return rows that should be visible and
> already locked by the current
Marko Tiikkaja wrote:
> On 2016-09-06 6:02 PM, Marti Raudsepp wrote:
> >This issue is also reproducible on the current master branch. In an
> >assertions-enabled build, it traps an assertion in HeapTupleHeaderGetCmax
> >called by heap_lock_tuple. The following test case demonstrates the issue...
>
On 2016-09-06 6:02 PM, Marti Raudsepp wrote:
This issue is also reproducible on the current master branch. In an
assertions-enabled build, it traps an assertion in HeapTupleHeaderGetCmax
called by heap_lock_tuple. The following test case demonstrates the issue...
I think you found a
