Re: dsa_allocate() faliure

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: dsa_allocate() faliure
Дата
Msg-id CAEepm=0m9PMTe3_+evvgOQPPxP1=hYNNoSdbE1o2FnqCqrFBwQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: dsa_allocate() faliure  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: dsa_allocate() faliure  (Thomas Munro <thomas.munro@enterprisedb.com>)
Re: dsa_allocate() faliure  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Sat, Feb 9, 2019 at 9:21 PM Robert Haas <robertmhaas@gmail.com> wrote:
> On Fri, Feb 8, 2019 at 8:00 AM Thomas Munro
> <thomas.munro@enterprisedb.com> wrote:
> > Sometimes FreeManagerPutInternal() returns a
> > number-of-contiguous-pages-created-by-this-insertion that is too large
> > by one. [...]
>
> I spent a long time thinking about this and starting at code this
> afternoon, but I didn't really come up with much of anything useful.
> It seems like a strange failure mode, because
> FreePageManagerPutInternal() normally just  returns its third argument
> unmodified. [...]

Bleugh.  Yeah.  What I said before wasn't quite right.  The value
returned by FreePageManagerPutInternal() is actually correct at the
moment it is returned, but it ceases to be correct immediately
afterwards if the following call to FreePageBtreeCleanup() happens to
reduce the size of that particular span.  The problem is that we
clobber fpm->contiguous_pages with the earlier (and by now incorrect)
value that we were holding in a local variable.

-- 
Thomas Munro
http://www.enterprisedb.com


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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Fixing findDependentObjects()'s dependency on scan order(regressions in DROP diagnostic messages)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages)