Re: [HACKERS] relation ### modified while in use

[Hiroshi Inoue]

Tom Lane wrote: > Alex Pilosov <[EMAIL PROTECTED]> writes: > > I think this happens after I create/modify tables which reference this > > table. This is spontaneous, and doesn't _always_ happen... > > Um. I was hoping it was something more easily fixable :-(. What's > causing the relcache to decide that the rel has been modified is the > addition or removal of foreign-key triggers on the rel. Which seems > legitimate. (It's barely possible that we could get away with allowing > triggers to be added or deleted mid-transaction, but that doesn't feel > right to me.) > > There are two distinct known bugs that allow the error to be reported. > These have been discussed before, but to recap: > > 1. relcache will complain if the notification of cache invalidation > arrives after transaction start and before first use of the referenced > rel (when there was already a relcache entry left over from a prior > transaction). In this situation we should allow the change to occur > without complaint, ISTM. But the relcache doesn't currently have any > concept of first reference versus later references. > Do we have a conclusion about this thread ? If no,how about changing heap_open(r) so that they allocate Relation descriptors after acquiring a lock on the table ? We would use LockRelation() no longer. Comments ? Regards. Hiroshi Inoue