Re: SSI patch version 14

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Jeff Davis" <pgsql(at)j-davis(dot)com>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: SSI patch version 14
Date: 2011-01-31 20:38:06
Message-ID: 4D46C94E020000250003A05E@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jeff Davis <pgsql(at)j-davis(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2011-01-31 20:41:51 Re: SSI patch version 14
Previous Message Bruce Momjian 2011-01-31 20:27:25 Re: Spread checkpoint sync