On Fri, Apr 6, 2018 at 8:59 PM, Andres Freund <andres@anarazel.de> wrote: > This is PROPARALLEL_RESTRICTED. That doesn't strike me right, shouldn't > they be PROPARALLEL_UNSAFE? It might be fine, but I'd not want to rely > on it.
Just a fine-grained note on this particular point:
It's totally fine for parallel-restricted operations to write WAL, write to the filesystem, or launch nukes at ${ENEMY_NATION}. Well, I mean, the last one might be a bad idea for geopolitical reasons, but it's not a problem for parallel query. It is a problem to insert or update heap tuples because it might extend the relation; mutual exclusion doesn't work properly there yet (there was a patch to fix that, but you had some concerns and it didn't go in). It is a problem to update or delete heap tuples which might create new combo CIDs; not all workers will have the same view (there's no patch for this yet AFAIK, but the fix probably doesn't look that different from cc5f81366c36b3dd8f02bd9be1cf75b2cc8482bd and could probably use most of the same infrastructure).
TL;DR: Writing pages (e.g. to set a checksum) doesn't make something non-parallel-safe. Writing heap tuples makes it parallel-unsafe.
That's a good summary, thanks!
Just to be clear in this case though -- the function itself doesn't write out *anything*. It only starts a background worker that later does it. The background worker itself is not parallelized, so the risk in this particular usecase would be that we ended up starting multiple workers (or just failed), I think.
But the summary is very good to have regardless! :)
