Re: post-freeze damage control

Поиск
Список
Период
Сортировка
От Jeff Davis
Тема Re: post-freeze damage control
Дата
Msg-id 55342358604f64437608ff7b8aaa8b296208e6ab.camel@j-davis.com
обсуждение исходный текст
Ответ на [MASSMAIL]post-freeze damage control  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: post-freeze damage control  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Mon, 2024-04-08 at 15:47 -0400, Robert Haas wrote:
> - I couldn't understand why the "Operate
> XLogCtl->log{Write,Flush}Result with atomics" code was correct when I
> read it.

I reviewed ee1cbe806d. It followed a good process of discussion and
review. It was a bit close to the feature freeze for comfort, but did
not feel rushed, to me.

Additional eyes are always welcome. There are also some related commits
in that area like f3ff7bf83b, c9920a9068 and 91f2cae7a4.

> But, a spinlock
> protecting two variables together guarantees more than atomic access
> to each of those variables separately.

We maintain the invariant:

   XLogCtl->logFlushResult <= XLogCtl->logWriteResult

and the non-shared version:

   LogwrtResult.Flush <= LogwrtResult.Write

and that the requests don't fall behind the results:

   XLogCtl->LogwrtRqst.Write >= XLogCtl->logWriteResult &&
   XLogCtl->LogwrtRqst.Flush >= XLogCtl->logFlushResult

Are you concerned that:

  (a) you aren't convinced that we're maintaining the invariants
properly? or
  (b) you aren't convinced that the invariant is strong enough, and
that there are other variables that we aren't considering?

And if you think this is right after all, where could we add some
clarification?

Regards,
    Jeff Davis




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

Предыдущее
От: Justin Pryzby
Дата:
Сообщение: Re: pg17 issues with not-null contraints
Следующее
От: David Steele
Дата:
Сообщение: Re: pg_combinebackup does not detect missing files