/*-------------------------------------------------------------------------
 *
 * resource_manager.c
 *	  GPDB resource manager code.
 *
 *
 * Copyright (c) 2006-2017, Greenplum inc.
 *
 *
 -------------------------------------------------------------------------
 */
#include "postgres.h"

#include "utils/guc.h"
#include "utils/resource_manager.h"

/*
 * GUC variables.
 */
bool	ResourceScheduler;						/* Is scheduling enabled? */
ResourceManagerPolicy Gp_resource_manager_policy;

/*-------------------------------------------------------------------------
 *
 * resource_manager.c
 *	  GPDB resource manager code.
 *
 *
 * Copyright (c) 2006-2017, Greenplum inc.
 *
 *
 -------------------------------------------------------------------------
 */
#include "postgres.h"

#include "utils/guc.h"
#include "utils/resource_manager.h"

/*
 * GUC variables.
 */
bool	ResourceScheduler = false;						/* Is scheduling enabled? */
ResourceManagerPolicy Gp_resource_manager_policy;

Initialize global var to avoid macOS linker error
Initialize global var to avoid macOS linker error

The macOS ld64 linker has an assertion on empty DATA segments
within linker Atoms. This assertion trips on the resource_manager
since it only contains uninitialized variables placed for the BSS
segment. This fails linking the backend on the resource_manager
SUBSYS object. Without anything initialized, an no exported
function symbols, the sections are:

$ nm -mgU src/backend/utils/resource_manager/SUBSYS.o
0000000000000004 (common) (alignment 2^2) external _Gp_resource_manager_policy
0000000000000001 (common) external _ResourceScheduler

With the initialization of the ResourceScheduler GUC variable:

$ nm -mgU src/backend/utils/resource_manager/SUBSYS.o
0000000000000004 (common) (alignment 2^2) external _Gp_resource_manager_policy
0000000000000004 (__DATA,__common) external _ResourceScheduler

Since the resource_manager in its current state is off anyways it
seems harmless to initialize to the correct value.
