From: | Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: relation ### modified while in use |
Date: | 2000-10-31 05:29:08 |
Message-ID: | 39FE58A4.EBC77E27@tpf.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Alex Pilosov <alex(at)pilosoft(dot)com> 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
From | Date | Subject | |
---|---|---|---|
Next Message | The Hermit Hacker | 2000-10-31 05:41:44 | Re: WAL status update |
Previous Message | Arnold Gamboa | 2000-10-31 05:25:04 | how good is PostgreSQL |