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

  1. Rethink the delay-checkpoint-end mechanism in the back-branches.

  2. Rename delayChkpt to delayChkptFlags.

  3. Fix possible recovery trouble if TRUNCATE overlaps a checkpoint.