Re: Question: pg_class attributes and race conditions ?

From: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
To: "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Pavan Deolasee" <pavan(dot)deolasee(at)enterprisedb(dot)com>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Question: pg_class attributes and race conditions ?
Date: 2007-03-16 21:45:49
Message-ID: 1174081549.4160.542.camel@silverbirch.site
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, 2007-03-16 at 16:59 -0400, Alvaro Herrera wrote:

> Here's is a very simple, low-tech idea. How about checking whether the
> new index requires chilling tuples; if it does, then elog(ERROR) until
> all the indexes have been manually chilled, which would be done with an
> "ALTER INDEX ... CHILL" command or something like that. Only when all
> indexes are known chilled, you can create another one, and then the user
> can "hotify" indexes as appropriate.

Well, I've spent two weeks searching for a design that does CREATE INDEX
without changing existing functionality. What's been proposed is very
close, but not exact.

CREATE INDEX CONCURRENTLY can work, so we're just discussing the other
increasingly edgy cases.

I agree some kind of compromise on CREATE INDEX seems to be required if
we want HOT without some drastic reductions in function. I'm happy to go
for low tech approaches, or anything really. Simple is good, so we can
hit feature freeze.

--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeremy Drake 2007-03-16 21:48:56 Re: Buildfarm feature request: some way to track/classify failures
Previous Message Andrew Dunstan 2007-03-16 21:32:04 Re: Buildfarm feature request: some way to track/classify failures