Re: POSIX shared memory redux
Re: POSIX shared memory redux
От:
A.M. <agentm@themactionfaction.com>
Дата:
Hello, Based on feedback from Tom Lane and Robert Haas, I have amended the POSIX shared memory patch to account for multiple-postmaster start race conditions (which is currently based on SysV shared memory checks). https://github.com/agentm/postgres/tree/posix_shmem To ensure that no two postmasters can startup in the same data directory, I use fcntl range locking on the data directory lock file, which also works properly on (properly configured) NFS volumes. Whenever a postmaster or postmaster child starts, it acquires a read (non-exclusive) lock on the data directory's lock file. When a new postmaster starts, it queries if anything would block a write (exclusive) lock on the lock file which returns a lock-holding PID in the case when other postgresql processes are running. Because POSIX fcntl locking is per-process and released in the kernel when a process ends, as long as there is a single process running and holding a read lock, no new postmaster can be started for that data directory. Furthermore, the fcntl syscall allows us to get a live PID for a conflicting lock-holding process, so the postgresql startup can print a live PID on a conflict startup. The contents of the data directory lock file remain the same, however, the PID stored in the lock file becomes less vital. The cost of this change is one additional file descriptor open in each postgresql process (for the full life of the process). As a gimmick, I also implemented a process-failover feature based on the F_SETLKW flag which allows a new postmaster to startup immediately if the running postmaster and all its children exit for any reason. This may also be useful to queue postmaster startup which could be controlled by a secondary non-postgresql process, pending some action (such as in a failover scenario). This feature is controlled via "postgres -b" (for "blocking"), but it is not vital to the shared memory implementation. Note that this implementation of the fcntl locking is effectively independent of the shared memory interface, i.e. this same locking could be used with the existing SysV shared memory scheme. Is this approach good enough to push to the next CommitFest? I am happy to amend the patch as necessary. Thanks! Cheers, M
