Re: [PATCH] /src/backend/access/transam/xlog.c, tiny improvements
От
Mark Dilger
Тема
Re: [PATCH] /src/backend/access/transam/xlog.c, tiny improvements
Дата
Msg-id
CB1EC25A-A595-420C-8DF9-A7DDB02C0470@enterprisedb.com
Ответ на
[PATCH] /src/backend/access/transam/xlog.c, tiny improvements (Ranier Vilela)
Список
Дерево обсуждения
[PATCH] /src/backend/access/transam/xlog.c, tiny improvements Ranier Vilela <ranier.vf@gmail.com>
Re: [PATCH] /src/backend/access/transam/xlog.c, tiny improvements Mark Dilger <mark.dilger@enterprisedb.com>
Re: [PATCH] /src/backend/access/transam/xlog.c, tiny improvements Michael Paquier <michael@paquier.xyz>
Re: [PATCH] /src/backend/access/transam/xlog.c, tiny improvements Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Re: [PATCH] /src/backend/access/transam/xlog.c, tiny improvements Ranier Vilela <ranier.vf@gmail.com>
> On Jan 24, 2020, at 12:48 PM, Ranier Vilela wrote: > > 3. At function KeepLogSeg (line 9357) the test if (slotSegNo <= 0), the var slotSegNo is uint64 and not can be < 0. There is something unusual about comparing a XLogSegNo variable in this way, but it seems to go back to 2014 when the replication slots were introduced in commit 858ec11858a914d4c380971985709b6d6b7dd6fc, and XLogSegNo was unsigned then, too. Depending on how you look at it, this could be a thinko, or it could be defensive programming against future changes to the XLogSegNo typedef. I’m betting it was defensive programming, given the context. As such, I don’t think it would be appropriate to remove this defense in your patch. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления
От: Michael Paquier
Дата:
От: Kyotaro Horiguchi
Дата: