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