On Thu, Nov 01, 2018 at 12:59:47PM -0400, Robert Haas wrote:
> If you do the same analysis for pg_start_backup(), you'll immediately
> notice that it calls get_backup_status(), and if you look at that
> function, you'll see that it returns the value of a global variable.
> If you check parallel.c, you'll find that that global variable is not
> one of the special ones that gets synchronized between a leader and
> the workers. Therefore, if you ran this function in a worker, it
> might do the wrong thing, because it might get the wrong value of that
> global variable. So it's at least (and in fact exactly)
> parallel-restricted. It doesn't need to be parallel-restricted
> because it's scary in some ill-defined way or any of these other
> reasons advanced on this thread -- it needs to be parallel-restricted
> because it *relies on a global variable that is not synchronized to
> parallel workers*. If somebody writes code to move that state out of
> a global variables and into the main shared memory segment or to a DSM
> shared between the leader and the workers, then it can be marked
> parallel-safe (unless, for example, it also depends on OTHER global
> variables that are NOT moved into shared storage). Otherwise not.
My name is all over the commit logs for this area, so I kind of heard
about what those things rely on.. Both exclusive and non-exclusive
backup interfaces are definitely unsafe to run across multiple processes
in the same query. Well, unsafe is incorrect for the pg_proc
definition, that's restricted :)
> I hope I'm making sense here.
You actually do a lot, moving just one person with MP as initials to
consider moving the function as being parallel-safe. Thanks for the
points you raised, what needs to be done looks clear now.
--
Michael