Re: API stability

Поиск
Список
Период
Сортировка
От Kyotaro Horiguchi
Тема Re: API stability
Дата
Msg-id 20220406.143037.1305948883608926192.horikyota.ntt@gmail.com
обсуждение исходный текст
Ответ на Re: API stability  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Ответы Re: API stability  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Konstantin Izmailov
Дата:
Сообщение: Re: zero char is returned as space
Следующее
От: "wangw.fnst@fujitsu.com"
Дата:
Сообщение: RE: Logical replication timeout problem