Re: API stability
Kyotaro Horiguchi <horikyota.ntt@gmail.com>
From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
To: alvherre@alvh.no-ip.org
Cc: robertmhaas@gmail.com, markus.wanner@enterprisedb.com,
pgsql-hackers@postgresql.org
Date: 2022-04-06T09:21:16Z
Lists: pgsql-hackers
At Wed, 06 Apr 2022 18:13:17 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in > At Wed, 6 Apr 2022 10:30:32 +0200, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote in > > For code documentation purposes, I think it is slightly better to use > > bits8 than uint8 for variables where you're storing independent bit flags. > > Oh, agreed. Will fix in the next version along with other fixes. The immediately folloing member statusFlags is in uint8. So using bits8 here results in the following look. > bits8 delayChkptFlags;/* for DELAY_CHKPT_* flags */ > > uint8 statusFlags; /* this backend's status flags, see PROC_* > * above. mirrored in PGPROC has another member that fits bits*. > uint64 fpLockBits; /* lock modes held for each fast-path slot */ Do I change this in this patch? Or leave them for another chance? regards. -- Kyotaro Horiguchi NTT Open Source Software Center
Commits
-
Rethink the delay-checkpoint-end mechanism in the back-branches.
- 48b398943b78 10.21 landed
- 6270ee445040 11.16 landed
- 68e605b9ef37 12.11 landed
- d18c913b786c 13.7 landed
- 10520f434687 14.3 landed
-
Rename delayChkpt to delayChkptFlags.
- f37015a1617d 15.0 landed
-
Fix possible recovery trouble if TRUNCATE overlaps a checkpoint.
- bbace5697df1 14.3 cited