From: | Aleksander Alekseev <aleksander(at)timescale(dot)com> |
---|---|
To: | Jacob Champion <jchampion(at)timescale(dot)com> |
Cc: | Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Maxim Orlov <orlovmg(at)gmail(dot)com>, Japin Li <japinli(at)hotmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Peter Geoghegan <pg(at)bowt(dot)ie>, Michael Paquier <michael(at)paquier(dot)xyz>, Ian Lawrence Barwick <barwick(at)gmail(dot)com>, Hamid Akhtar <hamid(dot)akhtar(at)percona(dot)com>, Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Alexander Korotkov <aekorotkov(at)gmail(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, Ilya Anfimov <ilan(at)tzirechnoy(dot)com> |
Subject: | Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15) |
Date: | 2023-01-17 13:32:56 |
Message-ID: | CAJ7c6TP6i7wsYoH-_A5rnKDJ9CZWZzDQ7DgkF4X2Fj7T-J5mig@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi hackers,
> Yeah, pg_upgrade will briefly start and stop the old server to make
> sure all the WAL is replayed, and won't transfer any of the files
> over. AFAIK, major-version WAL changes are fine; it was the previous
> claim that we could do it in a minor version that I was unsure about.
OK, here is the patchset v53 where I mostly modified the commit
messages. It is explicitly said that 0001 modifies the WAL records and
why we decided to do it in this patch. Additionally any mention of
64-bit XIDs is removed since it is not guaranteed that the rest of the
patches are going to be accepted. 64-bit SLRU page numbering is a
valuable change per se.
Changing the status of the CF entry to RfC apparently was a bit
premature. It looks like the patchset can use a few more rounds of
review.
In 0002:
```
-#define TransactionIdToCTsPage(xid) \
- ((xid) / (TransactionId) COMMIT_TS_XACTS_PER_PAGE)
+static inline int64
+TransactionIdToCTsPageInternal(TransactionId xid, bool lock)
+{
+ FullTransactionId fxid,
+ nextXid;
+ uint32 epoch;
+
+ if (lock)
+ LWLockAcquire(XidGenLock, LW_SHARED);
+
+ /* make a local copy */
+ nextXid = ShmemVariableCache->nextXid;
+
+ if (lock)
+ LWLockRelease(XidGenLock);
+
+ epoch = EpochFromFullTransactionId(nextXid);
+ if (xid > XidFromFullTransactionId(nextXid))
+ --epoch;
+
+ fxid = FullTransactionIdFromEpochAndXid(epoch, xid);
+
+ return fxid.value / (uint64) COMMIT_TS_XACTS_PER_PAGE;
+}
```
I'm pretty confident that shared memory can't be accessed like this,
without taking a lock. Although it may work on x64 generally we can
get garbage, unless nextXid is accessed atomically and has a
corresponding atomic type. On top of that I'm pretty sure
TransactionIds can't be compared with the regular comparison
operators. All in all, so far I don't understand why this piece of
code should be so complicated.
The same applies to:
```
-#define TransactionIdToPage(xid) ((xid) / (TransactionId)
SUBTRANS_XACTS_PER_PAGE)
+static inline int64
+TransactionIdToPageInternal(TransactionId xid, bool lock)
```
... in subtrans.c
Maxim, perhaps you could share with us what your reasoning was here?
--
Best regards,
Aleksander Alekseev
Attachment | Content-Type | Size |
---|---|---|
v53-0002-Utilize-64-bit-SLRU-page-numbers-in-SLRU-callers.patch | application/octet-stream | 24.4 KB |
v53-0001-Use-64-bit-numbering-of-SLRU-pages.patch | application/octet-stream | 37.8 KB |
v53-0003-pg_upgrade-from-32-bit-to-64-bit-SLRU-page-numbe.patch | application/octet-stream | 10.4 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2023-01-17 13:35:02 | Re: Extracting cross-version-upgrade knowledge from buildfarm client |
Previous Message | Amit Langote | 2023-01-17 13:31:23 | Re: SQL/JSON revisited |