Re: Concurrent CREATE INDEX, try 2 (was Re: Reducing relation locking overhead) - Mailing list pgsql-hackers

From Jochem van Dieten
Subject Re: Concurrent CREATE INDEX, try 2 (was Re: Reducing relation locking overhead)
Date
Msg-id f96a9b830512061150s396ed593s6187e04a9bd4ff5e@mail.gmail.com
Whole thread Raw
In response to Concurrent CREATE INDEX, try 2 (was Re: Reducing relation locking overhead)  (Hannu Krosing <hannu@skype.net>)
Responses Re: Concurrent CREATE INDEX, try 2 (was Re: Reducing relation locking overhead)  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Concurrent CREATE INDEX, try 2 (was Re: Reducing  (Hannu Krosing <hannu@skype.net>)
List pgsql-hackers
On 12/5/05, Hannu Krosing wrote:
>
> Concurrent CREATE INDEX
> ========================
>
> Concurrent index NDX1 on table TAB1 is created like this:
>
> 1) start transaction. take a snapshot SNAP1
>
> 1.1) optionally, remove pages for TAB1 from FSM to force (?) all newer
> inserts/updates to happen at end of table (won't work for in-page
> updates without code changes)
>
> 2) create the index as we do now, but only for pages which are visible
> in SNAP1
>
> 3) record the index in pg_class, but mark it as "do not use for lookups"
> in a new field. Take snapshot SNAP2. commit transaction.

What happens if another transaction takes a snapshot between SNAP2 and
the commit? Wouldn't you need a lock to guard against that? (Not that
I don't know if that is possible or desirable.)

Jochem

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Upcoming PG re-releases
Next
From: Michael Meskes
Date:
Subject: Re: Replication on the backend