Re: Assorted fixes related to WAL files (was: Use XLogFromFileName() in pg_resetwal to parse position from WAL file)
От | Bharath Rupireddy |
---|---|
Тема | Re: Assorted fixes related to WAL files (was: Use XLogFromFileName() in pg_resetwal to parse position from WAL file) |
Дата | |
Msg-id | CALj2ACW_GNB7B0DkL=_K-E6HyXQxtQoXejGaAL=JJgv4z-pSCg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Assorted fixes related to WAL files (was: Use XLogFromFileName() in pg_resetwal to parse position from WAL file) (Kyotaro Horiguchi <horikyota.ntt@gmail.com>) |
Ответы |
Re: Assorted fixes related to WAL files (was: Use XLogFromFileName() in pg_resetwal to parse position from WAL file)
|
Список | pgsql-hackers |
On Tue, Oct 4, 2022 at 2:01 PM Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote: > > > 1. 0001 replaces explicit WAL file parsing code with > > Looks good to me. > > > 2. 0002 replaces MAXPGPATH with MAXFNAMELEN for WAL file names. > > Looks reasonable, too. I don't find other instances of the same mistake. Thanks for reviewing. > > 3. 0003 replaces WAL file name calculation with XLogFileNameById() in > > pg_upgrade/controldata.c to be consistent across the code base. Note > > that this requires us to change the nextxlogfile size from hard-coded > > 25 bytes to MAXFNAMELEN (64 bytes). > > I'm not sure I like this. In other places where XLogFileNameById() is > used, the buffer is known to store longer strings so MAXFNAMELEN is > reasonable. But we don't need to add useless 39 bytes here. > Therefore, even if I wanted to change it, I would replace it with > "XLOG_FNAME_LEN + 1". I'm fine with doing either of these things. Let's hear from others. I've added a CF entry - https://commitfest.postgresql.org/40/3927/ -- Bharath Rupireddy PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
В списке pgsql-hackers по дате отправления: