Re: CREATE INDEX and HOT (was Question:pg_classattributes and race conditions ?)

From: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
To: "Merlin Moncure" <mmoncure(at)gmail(dot)com>
Cc: "Pavan Deolasee" <pavan(dot)deolasee(at)enterprisedb(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <pgsql-hackers(at)postgresql(dot)org>, "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>
Subject: Re: CREATE INDEX and HOT (was Question:pg_classattributes and race conditions ?)
Date: 2007-03-19 16:08:25
Message-ID: 1174320505.4160.818.camel@silverbirch.site
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 2007-03-19 at 10:29 -0500, Merlin Moncure wrote:
> On 3/17/07, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> > I'm very comfortable with the idea that HOT can be turned on/off for a
> > table. That gives us a workaround to bugs. Previously, changing things
> > like WITHOUT OIDS was done over two releases, so I'd suggest the same
> > thing here. Add the option now, disabled, then look to make it the
> > default option in the next release. We can override that with the
> > default_use_hot parameter for those that feel bold, at least initially.
> > I know Bruce has been long opposed to the idea of a table-level switch,
> > which is why we've been trying so hard to avoid it. So we should add his
> > -1 to this idea from the start.
>
> Is fear of bugs a justification of guc setting?

Probably not on its own, but the inspiration was that we currently have
user-visible behaviour in the recent proposals, hence the GUC.

> Or is there a trade-off involved with HOT?

At the moment, there is no downside to HOT in normal operation that I'm
aware of, but its a great question.

The problem we have is with normal CREATE INDEX because there are two
sources of race conditions that complicate this: concurrent index scans
and crash safety. Currently there are no perfect solutions to this. We
have two main options:
1. additional locking, either within CIDX or as a separate DDL
2. additional complexity and possible limitation in the number of
indexes to just 3 before we stop doing HOT updates.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Eric 2007-03-19 16:16:46 Re: initdb fails - postgresql does not support leap seconds
Previous Message Tom Lane 2007-03-19 15:42:17 Re: getTypeIOParam is wrong for domains over array types?