Re: CREATE INDEX and HOT - revised design

From: "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com>
To: "Csaba Nagy" <nagy(at)ecircle-ag(dot)com>
Cc: "Merlin Moncure" <mmoncure(at)gmail(dot)com>, "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>, "Bruce Momjian" <bruce(at)momjian(dot)us>, "postgres hackers" <pgsql-hackers(at)postgresql(dot)org>, "Pavan Deolasee" <pavan(dot)deolasee(at)enterprisedb(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Simon Riggs" <simon(at)2ndquadrant(dot)com>
Subject: Re: CREATE INDEX and HOT - revised design
Date: 2007-03-22 09:43:07
Message-ID: 2e78013d0703220243y75e02843j699aee9ad1385d52@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 3/22/07, Csaba Nagy <nagy(at)ecircle-ag(dot)com> wrote:
>
> > speaking with pavan off list he seems to think that only 'create
> > index' is outside transaction, not the other ddl flavors of it because
> > they are generally acquiring a excl lock. so, in that sense it is
> > possibly acceptable to me although still a pretty tough pill to
> > swallow (thinking, guc time). It would also preclude ever integrating
> > vanilla 'create index' to create table command, fwiw.
>
> Just to signal that it is in use: we did use create index in
> transactions occasionally when we had to do DB schema upgrade on
> production systems for application upgrades which span multiple versions
> of our application (normally we upgrade versions one by one, but we have
> some systems which are upgraded rarely). In these occasions it was
> riskier than usually to run the cumulated upgrade scripts outside a
> transaction block.
>
> But that was mostly a convenience feature, we could always rearrange our
> upgrade scripts to do all the rest first and then all the index creation
> at the end if all the rest succeeded... but if implicit index creation
> fails (e.g. when adding a new field to a table which happens also to be
> a primary key) inside the transaction, that would hurt... mostly in more
> work/more risks of extended downtime, but it will have a factor of
> inconvenience.
>
>
What I am hearing from many users is that its probably not such
a nice thing to put such restriction. Thats fair. It really helps to think
about a solution once you know what is acceptable and what is not.

I am back to the drawing board.

Thanks,
Pavan

--

EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hubert FONGARNAND 2007-03-22 09:53:47 Function cache regeneration
Previous Message Csaba Nagy 2007-03-22 09:22:48 Re: CREATE INDEX and HOT - revised design