From: | Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org, Jay Levitt <jay(dot)levitt(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com> |
Subject: | Re: Bugs/slowness inserting and indexing cubes |
Date: | 2012-02-15 08:18:34 |
Message-ID: | CAPpHfdvVC961FoBMA1SU7NBbQ5GtLwCt9jfzPffnFA8ZExcLHg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Feb 15, 2012 at 2:54 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Alexander Korotkov <aekorotkov(at)gmail(dot)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.
Attachment | Content-Type | Size |
---|---|---|
gist_build_fix2.patch | text/x-patch | 1.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2012-02-15 08:54:04 | Re: pg_test_fsync performance |
Previous Message | Zhou Han | 2012-02-15 07:01:42 | Re: client performance v.s. server statistics |