From: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Jakub Glapa <jakub(dot)glapa(at)gmail(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, Fabio Isabettini <fisabettini(at)voipfuture(dot)com>, Arne Roland <A(dot)Roland(at)index(dot)de>, Sand Stone <sand(dot)m(dot)stone(at)gmail(dot)com>, Rick Otten <rottenwindfish(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: dsa_allocate() faliure |
Date: | 2019-02-09 21:06:30 |
Message-ID: | CAEepm=2X8jDzJNj5UbnmdWcFfzRo6ZMpX2TAmApwzPc9thvo0w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-performance |
On Sun, Feb 10, 2019 at 7:24 AM Thomas Munro
<thomas(dot)munro(at)enterprisedb(dot)com> wrote:
> On Sat, Feb 9, 2019 at 9:21 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> > On Fri, Feb 8, 2019 at 8:00 AM Thomas Munro
> > <thomas(dot)munro(at)enterprisedb(dot)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.
... but why would it do that? I can reproduce cases where (for
example) FreePageManagerPutInternal() returns 179, and then
FreePageManagerLargestContiguous() returns 179, but then after
FreePageBtreeCleanup() it returns 178. At that point FreePageDump()
says:
btree depth 1:
77(at)0 l: 27(1) 78(178)
freelists:
1: 27
129: 78(178)
But at first glance it shouldn't be allocating pages, because it just
does consolidation to try to convert to singleton format, and then it
does recycle list cleanup using soft=true so that no allocation of
btree pages should occur.
--
Thomas Munro
http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2019-02-09 23:22:41 | Re: FETCH FIRST clause PERCENT option |
Previous Message | Tom Lane | 2019-02-09 20:52:52 | Re: Early WIP/PoC for inlining CTEs |
From | Date | Subject | |
---|---|---|---|
Next Message | Ricardo Martin Gomez | 2019-02-10 00:23:59 | Re: slow to run query 5000 times |
Previous Message | Thomas Munro | 2019-02-09 20:24:53 | Re: dsa_allocate() faliure |