Re: Possible uninitialized use of the variables (src/backend/access/transam/twophase.c)

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Possible uninitialized use of the variables (src/backend/access/transam/twophase.c)
Дата
Msg-id YgR6tP1Z0qxO5kE4@paquier.xyz
обсуждение исходный текст
Ответ на Re: Possible uninitialized use of the variables (src/backend/access/transam/twophase.c)  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Ответы Re: Possible uninitialized use of the variables (src/backend/access/transam/twophase.c)  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers
On Thu, Feb 10, 2022 at 10:18:15AM +0900, Kyotaro Horiguchi wrote:
> Who repoerted that to you?

Let's bet on Coverity.

> StartPrepare and EndPrepare are virtually a single function that
> accepts some additional operations in the middle.  StartPrepare leaves
> the "records" incomplete then EndPrepare completes it.  It is not
> designed so that the fields are accessed from others before the
> completion.  There seems to be no critical reasons for EndPrepare to
> do the pointed operations, but looking that another replorigin-related
> operation is needed in the same function, it is sensible that the
> author intended to consolidate all replorigin related changes in
> EndPrepare.

Well, that's the intention I recall from reading this code a couple of
weeks ago.  In the worst case, this could be considered as a bad
practice as having clean data helps at least debugging if you look at
this data between the calls of StartPrepare() and EndPrepare(), and we
do things this way for all the other fields, like total_len.

The proposed change is incomplete anyway once you consider this
argument.  First, there is no need to set up those fields in
EndPrepare() anymore if there is no origin data, no?  It would be good
to comment that these are filled in EndPrepare(), I guess, once you do
the initialization in StartPrepare().  I agree that those changes are
purely cosmetic.
--
Michael

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [RFC] building postgres with meson - perl embedding
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Logging in LockBufferForCleanup()