Re: [HACKERS] Reproducible vacuum complaint!

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(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Reproducible vacuum complaint!
Date: 1999-11-22 04:11:10
Message-ID: 21019.943243870@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:
> Hmm,if "select * .." runs in SERIALIZABLE isolation level,the transaction
> would see an old "msg_id=42" tuple(not new one). So vacuum doesn't
> vanish the old "msg_id=42" tuple. Vacuum takes all running transactions
> into account. But AFAIK,there's no other such stuff.
> CREATE INDEX may be another one which should take all running
> transactions into account.

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?

regards, tom lane

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Vadim Mikheev 1999-11-22 05:19:11 Re: [HACKERS] Reproducible vacuum complaint!
Previous Message Bruce Momjian 1999-11-22 02:46:45 Re: [HACKERS] New regression driver