Skip to content
Snippets Groups Projects
Select Git revision
  • benchmark-tools
  • postgres-lambda
  • master default
  • REL9_4_25
  • REL9_5_20
  • REL9_6_16
  • REL_10_11
  • REL_11_6
  • REL_12_1
  • REL_12_0
  • REL_12_RC1
  • REL_12_BETA4
  • REL9_4_24
  • REL9_5_19
  • REL9_6_15
  • REL_10_10
  • REL_11_5
  • REL_12_BETA3
  • REL9_4_23
  • REL9_5_18
  • REL9_6_14
  • REL_10_9
  • REL_11_4
23 results

postgres-lambda-diff

  • Clone with SSH
  • Clone with HTTPS
  • user avatar
    Tom Lane authored
    a backend has done exit(0) or exit(1) without having disengaged itself
    from shared memory.  We are at risk for this whenever third-party code is
    loaded into a backend, since such code might not know it's supposed to go
    through proc_exit() instead.  Also, it is reported that under Windows
    there are ways to externally kill a process that cause the status code
    returned to the postmaster to be indistinguishable from a voluntary exit
    (thank you, Microsoft).  If this does happen then the system is probably
    hosed --- for instance, the dead session might still be holding locks.
    So the best recovery method is to treat this like a backend crash.
    
    The dead man switch is armed for a particular child process when it
    acquires a regular PGPROC, and disarmed when the PGPROC is released;
    these should be the first and last touches of shared memory resources
    in a backend, or close enough anyway.  This choice means there is no
    coverage for auxiliary processes, but I doubt we need that, since they
    shouldn't be executing any user-provided code anyway.
    
    This patch also improves the management of the EXEC_BACKEND
    ShmemBackendArray array a bit, by reducing search costs.
    
    Although this problem is of long standing, the lack of field complaints
    seems to mean it's not critical enough to risk back-patching; at least
    not till we get some more testing of this mechanism.
    969d7cd4
    History
    Name Last commit Last update