Re: can while loop in ClockSweepTick function be kind of infinite loop in some cases?

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: can while loop in ClockSweepTick function be kind of infinite loop in some cases?
Дата
Msg-id 20230110185856.wmvchzish3hvorxm@awork3.anarazel.de
обсуждение исходный текст
Ответ на Re: can while loop in ClockSweepTick function be kind of infinite loop in some cases?  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: can while loop in ClockSweepTick function be kind of infinite loop in some cases?
Список pgsql-hackers
Hi,

On 2023-01-10 13:11:35 -0500, Robert Haas wrote:
> On Tue, Jan 10, 2023 at 12:40 PM Andres Freund <andres@anarazel.de> wrote:
> > > I think. `expected = originalVictim + 1;` line should be in while loop
> > > (before acquiring spin lock) so that, even in the case above, expected
> > > variable is incremented for each loop and CAS operation will be successful
> > > at some point.
> > > Is my understanding correct? If so, I will send PR for fixing this issue.
> >
> > Yes, I think your understanding might be correct. Interesting that this
> > apparently has never occurred.
>
> Doesn't pg_atomic_compare_exchange_u32 set expected if it fails?

Indeed, so there's no problem.

I wonder if we should make ->nextVictimBuffer a 64bit atomic. At the time the
changes went in we didn't (or rather, couldn't) rely on it, but these days we
could.  I think with a 64bit number we could get rid of ->completePasses and
just infer it from ->nextVictimBuffer/NBuffers, removing th need for the
spinlock.  It's very unlikely that 64bit would ever wrap, and even if, it'd
just be a small inaccuracy in the assumed number of passes. OTOH, it's
doubtful the overflow handling / the spinlock matters performance wise.

Greetings,

Andres Freund



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Fixing a couple of buglets in how VACUUM sets visibility map bits
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Avoiding "wrong tuple length" errors at the end of VACUUM on pg_database update (Backpatch of 947789f to v12 and v13)