On Mon, Aug 6, 2018 at 3:21 PM, Peter Geoghegan <pg@bowt.ie> wrote:
> On Mon, Aug 6, 2018 at 3:18 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Apparently there are people out there with catalogs big enough
>> to justify parallel reindex. I don't mind if the first version of
>> the feature doesn't handle that, but probably we should make it work
>> eventually.
>
> Okay. I'll pursue this in HEAD.
I wrote this in a little over an hour, and it works fine. I'll post it
shortly, once I polish it up some more. I'll also post an alternative
"no mapped relation parallel builds" fix for v11, which will be
trivial.
>> Well, maybe, but why is that field particularly vulnerable? I'd think you
>> should crosscheck the index's relfilenode too, at least, if you're going
>> to worry about that.
>
> I agree.
>
> I'd like to hear more opinions on the general idea. I'm particularly
> interested in what Robert thinks.
On second thought, the crosscheck of the index's relfilenode seems
like independent work. I won't be working on it as part of the fix for
this bug.
The question of index relfilenode becoming stale or inconsistent
doesn't come up with parallel CREATE INDEX, since currently the
workers never write to the new index relfilenode. If we were going to
do a similar crosscheck for parallel index scan, the new code would be
need to be spread across places like btbeginscan(), and
RelationGetIndexScan(). It's not something that can just be done in
passing.
--
Peter Geoghegan
