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
    When creating or manipulating a cached plan for a transaction control
    command (particularly ROLLBACK), we must not perform any catalog accesses,
    since we might be in an aborted transaction.  However, plancache.c busily
    saved or examined the search_path for every cached plan.  If we were
    unlucky enough to do this at a moment where the path's expansion into
    schema OIDs wasn't already cached, we'd do some catalog accesses; and with
    some more bad luck such as an ill-timed signal arrival, that could lead to
    crashes or Assert failures, as exhibited in bug #8095 from Nachiket Vaidya.
    Fortunately, there's no real need to consider the search path for such
    commands, so we can just skip the relevant steps when the subject statement
    is a TransactionStmt.  This is somewhat related to bug #5269, though the
    failure happens during initial cached-plan creation rather than
    revalidation.
    
    This bug has been there since the plan cache was invented, so back-patch
    to all supported branches.
    ac63dca6
    History
    Name Last commit Last update