On Tue, Aug 4, 2020 at 10:20 PM Robert Haas <robertmh...@gmail.com> wrote: > > On Tue, Aug 4, 2020 at 7:27 AM Bharath Rupireddy > <bharath.rupireddyforpostg...@gmail.com> wrote: > > I could get these points earlier in my initial analysis. In fact, I > > could figure out the flow on Windows, how these parameters are shared > > using a shared file(CreateFileMapping(), MapViewOfFile()), and the > > shared file name being passed as an argv[2] to the child process, and > > the way child process uses this file name to read the backend > > parameters in read_backend_variables(). > > Doesn't that happen even if the background worker isn't declared to > use BGWORKER_SHMEM_ACCESS? See StartBackgroundWorker(): IIUC, we start > with shared memory access, then afterwards detach. >
Yes, the bg worker starts with shared memory access even with no BGWORKER_SHMEM_ACCESS and later it gets detached in StartBackgroundWorker() with PGSharedMemoryDetach(). if ((worker->bgw_flags & BGWORKER_SHMEM_ACCESS) == 0) { dsm_detach_all(); PGSharedMemoryDetach(); } In EXEC_BACKEND cases, right after PGSharedMemoryDetach(), the bg worker will no longer be able to access the backend parameters, see below(I tried this on my Ubuntu machine with a bgworker with no BGWORKER_SHMEM_ACCESS flag and defined EXEC_BACKEND macro in pg_config_manual.h) : (gdb) p *MyLatch Cannot access memory at address 0x7fd60424a6b4 (gdb) p *ShmemVariableCache Cannot access memory at address 0x7fd58427bf80 (gdb) p ProcStructLock $10 = (slock_t *) 0x7fd60429bd00 <error: Cannot access memory at address 0x7fd60429bd00> (gdb) p *AuxiliaryProcs Cannot access memory at address 0x7fd60424cc60 (gdb) p *ProcGlobal Cannot access memory at address 0x7fd604232880 With Regards, Bharath Rupireddy. EnterpriseDB: http://www.enterprisedb.com