Re: Potential problem with HOT and indexes?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: Postgres <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Potential problem with HOT and indexes?
Date: 2009-03-26 19:41:47
Message-ID: 25965.1238096507@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Gregory Stark <stark(at)enterprisedb(dot)com> writes:
>> Another thought now though. What if someone updates the pg_index entry --
>> since we never reset indcheckxmin then the new tuple will have a new xmin and
>> will suddenly become invisible again for no reason.

> Fixing this for REINDEX is fairly straightforward I think. It already updates
> the pg_index line to fix indisvalid and indisready. see:

I realized what was bothering me about that patch: it could reset
indcheckxmin too soon, ie, while there are still transactions that
shouldn't use the index.

I propose that we modify it slightly: if we are updating a pg_index
row, and indcheckxmin is set, *and the old xmin is below the GlobalXmin
horizon*, then reset indcheckxmin. Otherwise leave it set, which will
mean that we postpone the time when the index becomes usable to
everyone, but it won't risk breaking anything.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2009-03-26 19:56:14 Re: Potential problem with HOT and indexes?
Previous Message Simon Riggs 2009-03-26 19:02:44 Re: maintenance_work_mem and autovacuum