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

connection.c

Blame
    • Tom Lane's avatar
      00d4f2af
      Improve connection-failure error handling in contrib/postgres_fdw. · 00d4f2af
      Tom Lane authored
      postgres_fdw tended to say "unknown error" if it tried to execute a command
      on an already-dead connection, because some paths in libpq just return a
      null PGresult for such cases.  Out-of-memory might result in that, too.
      To fix, pass the PGconn to pgfdw_report_error, and look at its
      PQerrorMessage() string if we can't get anything out of the PGresult.
      
      Also, fix the transaction-exit logic to reliably drop a dead connection.
      It was attempting to do that already, but it assumed that only connection
      cache entries with xact_depth > 0 needed to be examined.  The folly in that
      is that if we fail while issuing START TRANSACTION, we'll not have bumped
      xact_depth.  (At least for the case I was testing, this fix masks the
      other problem; but it still seems like a good idea to have the PGconn
      fallback logic.)
      
      Per investigation of bug #9087 from Craig Lucas.  Backpatch to 9.3 where
      this code was introduced.
      00d4f2af
      History
      Improve connection-failure error handling in contrib/postgres_fdw.
      Tom Lane authored
      postgres_fdw tended to say "unknown error" if it tried to execute a command
      on an already-dead connection, because some paths in libpq just return a
      null PGresult for such cases.  Out-of-memory might result in that, too.
      To fix, pass the PGconn to pgfdw_report_error, and look at its
      PQerrorMessage() string if we can't get anything out of the PGresult.
      
      Also, fix the transaction-exit logic to reliably drop a dead connection.
      It was attempting to do that already, but it assumed that only connection
      cache entries with xact_depth > 0 needed to be examined.  The folly in that
      is that if we fail while issuing START TRANSACTION, we'll not have bumped
      xact_depth.  (At least for the case I was testing, this fix masks the
      other problem; but it still seems like a good idea to have the PGconn
      fallback logic.)
      
      Per investigation of bug #9087 from Craig Lucas.  Backpatch to 9.3 where
      this code was introduced.