On Tue, Oct 03, 2023 at 07:02:11PM +0530, Bharath Rupireddy wrote: > On Tue, Oct 3, 2023 at 5:45 PM Drouvot, Bertrand > <bertranddrouvot...@gmail.com> wrote: >> I did some research and BGWORKER_BYPASS_ALLOWCONN has been added in >> eed1ce72e1 and >> at that time the bgw_flags did already exist. >> >> In this the related thread [1], Tom mentioned: >> >> " >> We change exported APIs in new major versions all the time. As >> long as it's just a question of an added parameter, people can deal >> with it. >> " > > It doesn't have to be always/all the time. If the case here is okay to > change the bgw and other core functions API, I honestly feel that we > must move BGWORKER_BYPASS_ALLOWCONN to bgw_flags.
I don't agree with this point. BackgroundWorkerInitializeConnection() and its other friend are designed to be called at the beginning of the main routine of a background worker, where bgw_flags is not accessible. There is much more happening before a bgworker initializes its connection, like signal handling and definitions of other states that depend on the GUCs loaded for the bgworker. >> Now, I understand your point but it looks to me that bgw_flags is more >> about the capabilities (Access to shared memory with BGWORKER_SHMEM_ACCESS >> or ability to establish database connection with >> BGWORKER_BACKEND_DATABASE_CONNECTION), >> >> While with BGWORKER_BYPASS_ROLELOGINCHECK (and BGWORKER_BYPASS_ALLOWCONN) >> it's more related to >> the BGW behavior once the capability is in place. > > I look at the new flag as a capability of the bgw to connect with a > role without login access. IMV, all are the same. Bertrand is arguing that the current code with its current split is OK, because both are different concepts: - bgw_flags is used by the postmaster to control how to launch the bgworkers. - The BGWORKER_* flags are used by the bgworkers themselves, once things are set up by the postmaster based on bgw_flags. -- Michael
signature.asc
Description: PGP signature
