Horton

Re: Bugs/slowness inserting and indexing cubes

Alexander Korotkov <aekorotkov@gmail.com>

View thread
From: Alexander Korotkov <aekorotkov@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>, pgsql-hackers@postgresql.org, Jay Levitt <jay.levitt@gmail.com>, Robert Haas <robertmhaas@gmail.com>
Date: 2012-02-15T08:18:34Z
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 →

  1. pg_dump: Further reduce reliance on global variables.

  2. Fix postmaster to attempt restart after a hot-standby crash.

Attachments

On Wed, Feb 15, 2012 at 2:54 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Alexander Korotkov <aekorotkov@gmail.com> writes:
> > 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.
> > But this assumptions becomes false we turn buffer off in the root page.
> So,
> > root page can produce pages without initialized buffers when splits.
>
> Hmm ... can we tighten the error check rather than just remove it?  It
> feels less than safe to assume that a hash-entry-not-found condition
> *must* reflect a corner-case situation like that.  At the very least
> I'd like to see it verify that we'd turned off buffering before deciding
> this is OK.  Better, would it be practical to make dummy entries in the
> hash table even after turning buffers off, so that the logic here
> becomes
>
>        if (!found) error;
>        else if (entry is dummy) return without doing anything;
>        else proceed;
>
>                        regards, tom lane
>

Ok, there is another patch fixes this problem. Instead of error triggering
remove it adds empty buffers on root page split if needed.

------
With best regards,
Alexander Korotkov.