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.
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 |