Re: online reindex

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: online reindex
Date: 2003-02-16 23:46:33
Message-ID: 87fzqnhjqe.fsf@stark.dyndns.tv
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Greg Stark <gsstark(at)mit(dot)edu> writes:
> > If reindex sets a flag that causes all new inserts and updates to allocate new
> > space at the end of the heap without checking for free space, then a simple
> > linear scan should be guaranteed to catch all the data.
>
> Oh? If people are inserting tuples at the same time you're reading, I'm
> not sure this holds good at all.

The premise is that reusing space within the heap is disabled during this
scan, so any new tuples are at the end. When you've reached the end you've
read all the ones inserted during your scan as well.

There is a window between the end of the scan and locking the table when more
extra tuples could be added but presumably that window would be small and the
extra tuples would be limited. They would have to be processed while the table
is locked.

I don't know much about postgres's locking yet, so I can't comment on how to
arrange to be able to get a lock on the table. At first blush this sounds like
there needs to be a "upgradable lock" that only one process can hold but
allows other processes to read while it's held until it's upgraded. But as I
said I don't know much details about the locking policies in use currently.

--
greg

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Lamar Owen 2003-02-16 23:56:57 Re: location of the configuration files
Previous Message Peter Eisentraut 2003-02-16 23:05:20 Re: psql and readline