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
signature.asc
Description: PGP signature
