Re: Lazy xid assignment V4

Pavan Deolasee wrote:
> On 9/4/07, Florian G. Pflug <fgp(at)phlo(dot)org> wrote:
>> Hi
>>
>> Here is an updated patch, following the discussion.
>> The patch can be found at: http://soc.phlo.org/lazyxidassign.v4.patch
>> (I seems I still can't get attachments through to this list)
>>
>>
> I haven't been able to follow the discussions here, but do I need to worry
> about its interaction with HOT ?

I don't think so. The interactions should be pretty minimal.

Any transaction that actually modifies a tuple will be assigned an xid
(That happens automatically if you call Get{Current|Top}TransactionId() ).
So those work just as they used to, only that the transaction id
is assigned a bit later. But GetSnapshotData() and friends deal correctly
with that.

It's only purely read-only transactions that behave a bit different.
AFAIK, with HOT, those still might try to prune and defragment a page - but they
won't need an xid for that I guess. Even if they did - calling
Get{Current|Top}TransctionId will assign one, so things should just work.

If you scan the procarray, and then wait for some of the transactions you found,
you might need to wait on the virtual transaction id instead of the regular
transaction id (because that might be InvalidTransactionId) - just as
CREATE INDEX CONCURRENTLY does. But the infrastructure for that is already in
place, so thats a rather trivial modification.

If HOT does change the second waiting phase of CREATE INDEX CONCURRENTLY to
use the new xidcreate (or however that is called) field, than that probably
replaces my changes to that code. That's fine - I knew that HOT might make
my changes unnecessary when I coded them, but I didn't want my patch to have a
dependency on HOT - that seemed to complicate things unnecessarily. And I
wasn't sure if HOT changes only normal CREATE INDEX, or both CREATE INDEX
and CREATE INDEX CONCURRENTLY.

greetings, Florian Pflug