Skip site navigation (1) Skip section navigation (2)

RE: [HACKERS] Duplicate index check in btbuild

From: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "pgsql-hackers" <pgsql-hackers(at)postgreSQL(dot)org>
Subject: RE: [HACKERS] Duplicate index check in btbuild
Date: 2000-01-31 23:55:25
Message-ID: 000301bf6c46$a4b50320$2801007e@tpf.co.jp (view raw or flat)
Thread:
Lists: pgsql-hackers
> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
> 
> "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> writes:
> > In addition I could find no other place to check
> > index uniqueness in tuplesort.c .
> > Seems we have to give up the uniqueness check in comparetup_
> > index() and have to check it in _bt_buildadd().
> 
> Checking index uniqueness in tuplesort is pretty much of a hack,
> although kind of cool since it doesn't take any extra comparisons
> to do it there.  But if we're doing the wrong thing then it has
> to be removed.
> 
> I'm a little unclear on *why* it's wrong though.  Don't we grab an
> exclusive lock on a table while building an index for it?  (If not,
> shouldn't we be doing so?)  I don't see how there can be tuples of
> uncertain commit state that need to be included in the index.
>

It's what you pointed out in [[HACKERS] Reproducible vacuum complaint!]
2 months ago.

> Oh, I think I see --- you mean that CREATE INDEX needs to make index
> entries for tuples that are committed dead but might still be visible
> to some running transaction somewhere.  Yes, that seems to fit what
> I was seeing.  VACUUM always complained that there were too few
> index entries, never too many.

> It looks like btbuild() only indexes tuples that satisfy SnapshotNow,
> so this is definitely a potential problem for btree indexes.  The other
> index types are likely broken in the same way...
>
> Comments anyone?  What time qual should btbuild and friends be using,
> if not that?

Same phenomenon was found in Marc's recent posting [HACKERS] [6.5.2]
potentially major bug?]. After changing SnapshotNow -> SnapshotAny I tried
and found that comparetup_index() rejects duplicate index tuples.

Regards.

Hiroshi Inoue
Inoue(at)tpf(dot)co(dot)jp  




In response to

pgsql-hackers by date

Next:From: Philip WarnerDate: 2000-02-01 00:53:30
Subject: The Apache Model (was Re: Copyright)
Previous:From: Timothy DyckDate: 2000-01-31 22:29:05
Subject: request for tuning suggestions from PC Week Labs

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group