Re: API stability - Mailing list pgsql-hackers

From Kyotaro Horiguchi
Subject Re: API stability
Date
Msg-id 20220406.143037.1305948883608926192.horikyota.ntt@gmail.com
Whole thread Raw
In response to Re: API stability  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Responses Re: API stability  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
List pgsql-hackers
me> I'd like to do that. Let me see.

At Tue, 5 Apr 2022 10:29:03 -0400, Robert Haas <robertmhaas@gmail.com> wrote in 
> On Tue, Apr 5, 2022 at 10:17 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > What I think you need to do is:
> >
> > 1. In the back branches, revert delayChkpt to its previous type and
> > semantics.  Squeeze a separate delayChkptEnd bool in somewhere
> > (you can't change the struct size either ...).
> >
> > 2. In HEAD, rename the field to something like delayChkptFlags,
> > to ensure that any code touching it has to be inspected and updated.
> 
> Well, we can do it that way, I suppose.

The change is easy on head, but is it better use uint8 instead of int
for delayChkptFlags?

In the back branches, we have, on gcc/Linux/x86-64,
14's PGPROC is 880 bytes and has gaps:

- 6 bytes after statusFlag
- 4 bytes after syncRepState
- 2 bytes after subxidStatus
- 3 bytes after procArrayGroupMember
- 3 bytes after clogGroupMember
- 3 bytes after fpVXIDLock

It seems that we can place the new variable in the first place above,
since the two are not bonded together, or at least in less tightly
bonded than other candidates.

13's PGPROC is 856 bytes and has a 7 bytes gap after delayChkpt.

Versions Ealier than 13 have delayChkpt in PGXACT (12 bytes).  It is
tightly packed and dones't have a room for a new member.  Can we add
the new flag to PGPROC instead of PGXACT?
  
12 and 11's PGPROC is 848 bytes and has gaps:
   - 4 bytes after syncRepState
   - 3 bytes after procArrayGroupMember
   - 3 bytes after clogGroupMember
   - 4 bytes after clogGroupMemberPage
   - 3 bytes after fpVXIDLock


10's PGPROC is 816 bytes and has gaps:
   - 4 bytes after cvWaitLink
   - 4 bytes after syncRepState
   - 3 bytes after procArrayGroupMember
   - 3 bytes after fpVXIDLock

So if we don't want to move any member in PGPROC, we do:

14: after statusFlags.
13: after delayChkpt.
12-10: after syncRepState (and before syncRepLinks).

If we allow to shift some members, the new flag can be placed more
saner place.

14: after delayChkpt ((uint8)statusFlags moves forward by 1 byte)
13: after delayChkpt (no member moves)
12-10: after subxids ((bool)procArrayGroupMember moves forward by 1 byte)

I continue working on the last direction above.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: Konstantin Izmailov
Date:
Subject: Re: zero char is returned as space
Next
From: "wangw.fnst@fujitsu.com"
Date:
Subject: RE: Logical replication timeout problem