Re: Bugs/slowness inserting and indexing cubes
Alexander Korotkov <aekorotkov@gmail.com>
From: Alexander Korotkov <aekorotkov@gmail.com>
To: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
Cc: pgsql-hackers@postgresql.org, Jay Levitt <jay.levitt@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>
Date: 2012-02-14T22:09:24Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
pg_dump: Further reduce reliance on global variables.
- 1631598ea204 9.2.0 cited
-
Fix postmaster to attempt restart after a hot-standby crash.
- ef19c9dfaa99 9.1.3 cited
Attachments
- gist_build_fix.patch (text/x-patch) patch
ITSM, I found the problem. This piece of code is triggering an error. It
assumes each page of corresponding to have initialized buffer. That should
be true because we're inserting index tuples from up to down while
splits propagate from down to up.
if (!found)
{
/*
* Node buffer should exist at this point. If it didn't exist before,
* the insertion that caused the page to split should've created it.
*/
elog(ERROR, "node buffer of page being split (%u) does not exist",
blocknum);
}
But this assumptions becomes false we turn buffer off in the root page. So,
root page can produce pages without initialized buffers when splits.
/*
* Does specified level have buffers? (Beware of multiple evaluation of
* arguments.)
*/
#define LEVEL_HAS_BUFFERS(nlevel, gfbb) \
((nlevel) != 0 && (nlevel) % (gfbb)->levelStep == 0 && \
(nlevel) != (gfbb)->rootitem->level)
So, I think we should just do silent return from the function instead of
triggering error. Patch is attached.
------
With best regards,
Alexander Korotkov.