Re: [HACKERS] Duplicate index check in btbuild

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>
Cc: "pgsql-hackers" <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: [HACKERS] Duplicate index check in btbuild
Date: 2000-01-31 16:00:57
Message-ID: 9990.949334457@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ed Loehr 2000-01-31 16:31:39 Re: [HACKERS] float4 confused as int??
Previous Message Tom Lane 2000-01-31 15:52:35 Re: [HACKERS] float4 confused as int??