Tom Lane <tgl@sss.pgh.pa.us> writes:
> Greg Stark <gsstark@mit.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