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

trigger.c

Blame
    • Robert Haas's avatar
      4240e429
      Try to acquire relation locks in RangeVarGetRelid. · 4240e429
      Robert Haas authored
      In the previous coding, we would look up a relation in RangeVarGetRelid,
      lock the resulting OID, and then AcceptInvalidationMessages().  While
      this was sufficient to ensure that we noticed any changes to the
      relation definition before building the relcache entry, it didn't
      handle the possibility that the name we looked up no longer referenced
      the same OID.  This was particularly problematic in the case where a
      table had been dropped and recreated: we'd latch on to the entry for
      the old relation and fail later on.  Now, we acquire the relation lock
      inside RangeVarGetRelid, and retry the name lookup if we notice that
      invalidation messages have been processed meanwhile.  Many operations
      that would previously have failed with an error in the presence of
      concurrent DDL will now succeed.
      
      There is a good deal of work remaining to be done here: many callers
      of RangeVarGetRelid still pass NoLock for one reason or another.  In
      addition, nothing in this patch guards against the possibility that
      the meaning of an unqualified name might change due to the creation
      of a relation in a schema earlier in the user's search path than the
      one where it was previously found.  Furthermore, there's nothing at
      all here to guard against similar race conditions for non-relations.
      For all that, it's a start.
      
      Noah Misch and Robert Haas
      4240e429
      History
      Try to acquire relation locks in RangeVarGetRelid.
      Robert Haas authored
      In the previous coding, we would look up a relation in RangeVarGetRelid,
      lock the resulting OID, and then AcceptInvalidationMessages().  While
      this was sufficient to ensure that we noticed any changes to the
      relation definition before building the relcache entry, it didn't
      handle the possibility that the name we looked up no longer referenced
      the same OID.  This was particularly problematic in the case where a
      table had been dropped and recreated: we'd latch on to the entry for
      the old relation and fail later on.  Now, we acquire the relation lock
      inside RangeVarGetRelid, and retry the name lookup if we notice that
      invalidation messages have been processed meanwhile.  Many operations
      that would previously have failed with an error in the presence of
      concurrent DDL will now succeed.
      
      There is a good deal of work remaining to be done here: many callers
      of RangeVarGetRelid still pass NoLock for one reason or another.  In
      addition, nothing in this patch guards against the possibility that
      the meaning of an unqualified name might change due to the creation
      of a relation in a schema earlier in the user's search path than the
      one where it was previously found.  Furthermore, there's nothing at
      all here to guard against similar race conditions for non-relations.
      For all that, it's a start.
      
      Noah Misch and Robert Haas