Re: trying again to get incremental backup
От | Robert Haas |
---|---|
Тема | Re: trying again to get incremental backup |
Дата | |
Msg-id | CA+Tgmob5nehWdboo_7K6jS8Oy_tfBrhZxNwMtrQ+kCReVqZzrA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: trying again to get incremental backup (Thomas Munro <thomas.munro@gmail.com>) |
Список | pgsql-hackers |
On Thu, Nov 23, 2023 at 11:18 PM Thomas Munro <thomas.munro@gmail.com> wrote: > Robert pinged me to see if I had any ideas. Thanks, Thomas. > The reason it fails on Windows is because there is a special code path > for WIN32 in the patch's src/bin/pg_combinebackup/copy_file.c, but it > is incomplete: it returns early without feeding the data into the > checksum, so all the checksums have the same initial and bogus value. > I commented that part out so it took the normal path like Unix, and it > passed. Yikes, that's embarrassing. Thanks for running it down. There is logic in the caller to figure out whether we need to recompute the checksum or can reuse one we already have, but copy_file() doesn't understand that it should take the slow path if a new checksum computation is required. > The reason it fails on Linux 32 bit with -fsanitize is because this > has uncovered a bug in xlogreader.c, which overflows a 32 bit pointer > when doing a size test that could easily be changed to non-overflowing > formulation. AFAICS it is not a live bug because it comes to the > right conclusion without deferencing the pointer due to other checks, > but the sanitizer is not wrong to complain about it and I will post a > patch to fix that in a new thread. With the draft patch I am testing, > the sanitizer is happy and this passes too. Thanks so much. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: