Re: SSI patch version 14 - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: SSI patch version 14
Date
Msg-id 4D46C94E020000250003A05E@gw.wicourts.gov
Whole thread Raw
In response to Re: SSI patch version 14  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: SSI patch version 14  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Re: SSI patch version 14  (Jeff Davis <pgsql@j-davis.com>)
List pgsql-hackers
Jeff Davis <pgsql@j-davis.com> wrote:
> On Mon, 2011-01-31 at 13:55 -0600, Kevin Grittner wrote:
>> What it cares about is whether some other particular top level
>> transaction wrote a tuple which we *would* read except that it is
>> not visible to us because that other top level transaction is
>> concurrent with ours.
> 
> Or a tuple that you *are* reading, but is being deleted
> concurrently, right? Or has been deleted by an overlapping
> transaction?
Right.  I guess that wasn't as precise a statement as I thought.  I
was trying to say that the effects of some write (insert, update,
delete to a permanent table) would not be visible to us because the
writing transaction is concurrent, for some tuple under
consideration.
>> If so, we want to flag a read-write conflict
>> out from our transaction and in to that other transaction.
> 
> It still seems like HTSV would suffice, unless I'm missing
> something.
It is at least as likely that I'm missing something.  If I'm
following you, we're talking about these 24 lines of code, where
"valid" is the what was just returned from
HeapTupleSatisfiesVisibility:   if (valid)   {       /*        * We may bail out if previous xmax aborted, or if it
committed but        * only locked the tuple without updating it.        */       if (tuple->t_data->t_infomask &
(HEAP_XMAX_INVALID|
 
HEAP_IS_LOCKED))           return;
       /*        * If there's a valid xmax, it must be from a concurrent
transaction,        * since it deleted a tuple which is visible to us.        */       xid =
HeapTupleHeaderGetXmax(tuple->t_data);      if (!TransactionIdIsValid(xid))           return;   }   else   {       /*
    * We would read this row, but it isn't visible to us.        */       xid = HeapTupleHeaderGetXmin(tuple->t_data);
}
 
We follow this by a check for the top-level xid, and return if
that's early enough to have overlapped our transaction.
This seems to work as intended for a all known tests.  I guess my
questions would be:
(1)  Do you see a case where this would do the wrong thing?  Can you
describe that or (even better) provide a test case to demonstrate
it?
(2)  I haven't gotten my head around how HTSV helps or is even the
right thing.  If I want to try the switch statement from your recent
post, what should I use as the OldestXmin value on the call to HTSV?
-Kevin


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Spread checkpoint sync
Next
From: "Kevin Grittner"
Date:
Subject: Re: SSI patch version 14