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
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 |
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 |