On Tue, Apr 10, 2018 at 6:18 PM, Robert Haas <robertmh...@gmail.com> wrote:

> On Fri, Apr 6, 2018 at 8:59 PM, Andres Freund <and...@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! :)

 Magnus Hagander
 Me: https://www.hagander.net/ <http://www.hagander.net/>
 Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>

Reply via email to