Tracking commit LSNs of tuple xmins for read txns

From: Tejasvi Kashi <mail(at)tejasvi(dot)dev>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Tracking commit LSNs of tuple xmins for read txns
Date: 2023-06-05 22:18:01
Message-ID: CAJWWkaqqZF0tHVAhNznU4ck6sgM9EfbDwCfOwA3ZTUtE_s7tXw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

Browse pgsql-hackers by date

  From Date Subject
Next Message Joe Conway 2023-06-05 22:32:42 Re: Inconsistent results with libc sorting on Windows
Previous Message Daniel Verite 2023-06-05 22:07:58 Inconsistent results with libc sorting on Windows