Re: API stability

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: robertmhaas(at)gmail(dot)com
Cc: markus(dot)wanner(at)enterprisedb(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: API stability
Date: 2022-04-06 05:30:37
Message-ID: 20220406.143037.1305948883608926192.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

me> I'd like to do that. Let me see.

At Tue, 5 Apr 2022 10:29:03 -0400, Robert Haas <robertmhaas(at)gmail(dot)com> wrote in
> On Tue, Apr 5, 2022 at 10:17 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Peter Eisentraut 2022-04-06 06:18:55 pgsql: Update Unicode data to CLDR 41
Previous Message Amit Kapila 2022-04-06 02:52:51 pgsql: Improve comments for row filtering and toast interaction in logi

Browse pgsql-hackers by date

  From Date Subject
Next Message wangw.fnst@fujitsu.com 2022-04-06 05:39:05 RE: Logical replication timeout problem
Previous Message Konstantin Izmailov 2022-04-06 05:23:53 Re: zero char is returned as space