Kevin Grittner wrote:
> In going over this, I found pre-existing bugs when a tuple was both
> inserted and deleted by concurrent transactions, but fixing that is
> too invasive to consider for Monday's minor release lockdown. The
> attached seems very safe to me, and protects against some new
>
Andres Freund wrote:
> Looking at predicate.c I think I see a bigger problem though: Isn't its
> usage of HeapTupleSatisfiesVacuum() quite dangerous? It passes
> TransactionXmin to HeapTupleSatisfiesVacuum(). But since that's just the
> transaction's own cutoff, not the global cutoff that will ca
On 2013-11-29 22:27:16 +0100, Andres Freund wrote:
> Looking at predicate.c I think I see a bigger problem though: Isn't its
> usage of HeapTupleSatisfiesVacuum() quite dangerous? It passes
> TransactionXmin to HeapTupleSatisfiesVacuum(). But since that's just the
> transaction's own cutoff, not th
On 2013-11-29 13:14:06 -0800, Kevin Grittner wrote:
> Andres Freund wrote:
> > On 2013-11-27 15:42:11 -0800, Kevin Grittner wrote:
>
> >> What back-patching will be needed for a fix? It sounds like
> >> 9.3?
> >
> > Yep.
>
> In going over this, I found pre-existing bugs when a tuple was both
>
Andres Freund wrote:
> On 2013-11-27 15:42:11 -0800, Kevin Grittner wrote:
>> What back-patching will be needed for a fix? It sounds like
>> 9.3?
>
> Yep.
In going over this, I found pre-existing bugs when a tuple was both
inserted and deleted by concurrent transactions, but fixing that is
too
On 2013-11-27 15:42:11 -0800, Kevin Grittner wrote:
> Andres Freund wrote:
> > What do you mean with "how far back"?
>
> What back-patching will be needed for a fix? It sounds like 9.3?
Yep.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreS
Andres Freund wrote:
> On 2013-11-27 15:14:11 -0800, Kevin Grittner wrote:
>> ... however, I have not been able to trigger that Assert even with
>> gdb breakpoints at what I think are the right spots. Any
>> suggestions? How far back is it true that the above
>> HeapTupleSatisfiesVacuum() can r
On 2013-11-27 15:14:11 -0800, Kevin Grittner wrote:
> Andres Freund wrote:
>
> > HeapTupleHeaderGetUpdateXid() ignores aborted updaters
> > and returns InvalidTransactionId in that case, but
> > HeapTupleSatisfiesVacuum() returns HEAPTUPLE_DELETE_IN_PROGRESS...
>
> That sure *sounds* like it sho
Andres Freund wrote:
> HeapTupleHeaderGetUpdateXid() ignores aborted updaters
> and returns InvalidTransactionId in that case, but
> HeapTupleSatisfiesVacuum() returns HEAPTUPLE_DELETE_IN_PROGRESS...
That sure *sounds* like it should cause a problem for this code in
CheckForSerializableConflictO
Alvaro Herrera wrote:
> Andres Freund wrote:
>> That's because HeapTupleHeaderGetUpdateXid() ignores aborted
>> updaters and returns InvalidTransactionId in that case, but
>> HeapTupleSatisfiesVacuum() returns
>> HEAPTUPLE_DELETE_IN_PROGRESS...
> I checked for other cases where the update Xid is
On 2013-11-25 13:45:53 -0300, Alvaro Herrera wrote:
> Andres Freund wrote:
> > On 2013-11-25 12:36:19 -0300, Alvaro Herrera wrote:
>
> > > There is no way to close the window, but there is no need; if the
> > > updater aborted, we don't need to mark the page prunable in the first
> > > place. So
Andres Freund wrote:
> On 2013-11-25 12:36:19 -0300, Alvaro Herrera wrote:
> > There is no way to close the window, but there is no need; if the
> > updater aborted, we don't need to mark the page prunable in the first
> > place. So we can just check the return value of
> > HeapTupleHeaderGetUpda
On 2013-11-25 12:36:19 -0300, Alvaro Herrera wrote:
> > 2) we frequently error out in heap_lock_updated_tuple_rec() with
> > ERROR: unable to fetch updated version of tuple
> >
> > That's because when we're following a ctid chain, it's perfectly
> > possible for the updated version of a tuple to
Andres Freund wrote:
Hi,
> The attached pgbench testcase can reproduce two issues:
Thanks.
> 2) we frequently error out in heap_lock_updated_tuple_rec() with
> ERROR: unable to fetch updated version of tuple
>
> That's because when we're following a ctid chain, it's perfectly
> possible for t
Hi,
The attached pgbench testcase can reproduce two issues:
1) (takes a bit)
TRAP: FailedAssertion("!(((xid) >= ((TransactionId) 3)))", File:/pruneheap.c",
Line: 601)
That's because HeapTupleHeaderGetUpdateXid() ignores aborted updaters
and returns InvalidTransactionId in that case, but
HeapTupl
15 matches
Mail list logo
