Re: Rework the way multixact truncations work

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Rework the way multixact truncations work
Дата
Msg-id 20151209162051.GK28762@awork2.anarazel.de
обсуждение исходный текст
Ответ на Re: Rework the way multixact truncations work  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On 2015-12-09 11:18:39 -0500, Robert Haas wrote:
> If I correctly understand the scenario that you are describing, that
> does happen - not for the same MXID, but for different ones.  At least
> the last time I checked, and I'm not sure if we've fixed this, it
> could happen because the SLRU page that contains the multixact wasn't
> flushed out of the SLRU buffers yet.

That should be fixed, with the brute force solution of flushing buffers
before searching for files on disk.

> But apart from that, it could
> happen any time there's a gap in the sequence of files, and that sure
> doesn't seem like a can't-happen situation.  We know that, on 9.3,
> there's definitely a sequence of events that leads to a 0000 file
> followed by a gap followed by the series of files that are still live.
> Given the number of other bugs we've fixed in this area, I would not
> like to bet on that being the only scenario where this crops up.  It
> *shouldn't* happen, and as far as we know, if you start and end on a
> version newer than 4f627f8 and aa29c1c, it won't.  Older branches,
> though, I wouldn't like to bet on.

Ok, fair enough.

andres



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Rework the way multixact truncations work
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Foreign join pushdown vs EvalPlanQual