Tracking commit LSNs of tuple xmins for read txns - Mailing list pgsql-hackers

From Tejasvi Kashi
Subject Tracking commit LSNs of tuple xmins for read txns
Date
Msg-id CAJWWkaqqZF0tHVAhNznU4ck6sgM9EfbDwCfOwA3ZTUtE_s7tXw@mail.gmail.com
Whole thread Raw
List pgsql-hackers
Hi everyone,

When a transaction reads tuples from the heap, I would like to keep track of the maximum commit LSN of the xmin transactions of tuples as they are read. For e.g., consider a transaction T that reads tuples [t1, t2, t3] with respective xmins [700, 705, 702] and respective commit LSNs [8000, 9000, 10000]. I would like to record that T has read a max commit LSN of 10000.

Currently, I have changed TransactionIdCommitTree() so that all transactions have their commit LSN stored (and not just synchornous_commit = off ones). I am also able to read a recent transaction's commit LSN using TransactionIdGetCommitLSN().

I have looked at heapam.c, and sort of understand where this logic needs to go. However, I'm not fully sure how to keep track of this "maxLSN" among all commit LSNs of tuple xmins. My first attempt was to update a new member "maxLSN" of the SnapshotData struct as tuples are read, and I get their commit LSNs. However, this slowed down reads by a lot.

As I understand, looking up the clog for every tuple's xmin is an expensive operation. So I was thinking of adding a new member to the HeapTupleHeader called 'commitLSN' which gets updated as hint bits are set. I'm not sure, however, if this is the right way to go. Then, there's also the question of what to use to update the 'maxLSN' -- should I update SnapshotData? Or do something else?

I would greatly appreciate any pointers on how to go about this :)

Sincerely,
Tej Kashi
MMath CS (thesis) @ UWaterloo
Waterloo, Canada

P.S. I am not trying to submit a patch/feature. I am modifying Postgres for my master's thesis.  

pgsql-hackers by date:

Previous
From: "Daniel Verite"
Date:
Subject: Inconsistent results with libc sorting on Windows
Next
From: Joe Conway
Date:
Subject: Re: Inconsistent results with libc sorting on Windows