Peter Geoghegan <pg@bowt.ie> writes:
> On Mon, Aug 6, 2018 at 2:29 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Hm. Post-beta3, I think I'd vote for a conservative fix in v11,
>> which seems to be "ban for mapped catalogs". Feel free to make
>> it work in HEAD, though.
> Makes sense. I'm not sure if it's worth pursuing parallel mapped
> catalog index builds much further, though. I doubt that ordinary users
> care about whether or not this is supported, so this is a matter of
> principle. I don't feel strongly on whether or not I should make
> mapped builds work on HEAD, so I defer to you, and anyone else that
> might have an interest. Does it matter, do you think?
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.
> It might be worth teaching heap_beginscan_parallel() to
> cross-check each worker's heap relation's rd_smgr.smgr_node to a version
> of the same field from the leader, stored in shared memory (in the
> ParallelHeapScanDesc). That way, any future recurrence of a similar
> bug will be far easier to detect. A "can't happen" error along these
> lines seems like it would be worthwhile.
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.
regards, tom lane
