On Thu, Sep 02, 2021 at 04:46:56PM +0000, Bossart, Nathan wrote: > Yeah, huge_pages_required might not serve much purpose for Windows. > We could always set it to -1 for Windows if it seems like it'll do > more harm than good.
I'd be fine with this setup on environments where there is no need for it. >> At the end it would be nice to not finish with two GUCs. Both depend >> on the reordering of the actions done by the postmaster, so I'd be >> curious to hear the thoughts of others on this particular point. > > Of course. It'd be great to hear others' thoughts on this stuff. Just to be clear here, the ordering of HEAD is that for the postmaster: - Load configuration. - Handle -C config_param. - checkDataDir(), to check permissions of the data dir, etc. - checkControlFile(), to see if the control file exists. - Switch to data directory as work dir. - Lock file creation. - Initial read of the control file (where the GUC data_checksums is set). - Register apply launcher - shared_preload_libraries With 0002, we have that: - Load configuration. - checkDataDir(), to check permissions of the data dir, etc. - checkControlFile(), to see if the control file exists. - Switch to data directory as work dir. - Register apply launcher - shared_preload_libraries - Calculate the shmem GUCs (new step) - Handle -C config_param. - Lock file creation. - Initial read of the control file (where the GUC data_checksums is set). One thing that would be incorrect upon more review is that we'd still have data_checksums wrong with -C, meaning that the initial read of the control file should be moved further up, and getting the control file checks done before registering workers would be better. Keeping the lock file at the end would be fine AFAIK, but should we worry about the interactions with _PG_init() here? 0001, that refactors the calculation of the shmem size into a different routine, is fine as-is, so I'd like to move on and apply it. -- Michael
signature.asc
Description: PGP signature
