Tom Lane wrote:
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > RelationCacheInvalidate() is called from ResetSystemCaches()
> > and calles RelationFlushRelation() for all relation descriptors
> > except some nailed system relations.
> > I'm wondering why nailed relations could be exceptions.
> >
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> RelationCacheInvalidate() is called from ResetSystemCaches()
> and calles RelationFlushRelation() for all relation descriptors
> except some nailed system relations.
> I'm wondering why nailed relations could be exceptions.
> Conversely why must Relation
Hi
RelationCacheInvalidate() is called from ResetSystemCaches()
and calles RelationFlushRelation() for all relation descriptors
except some nailed system relations.
I'm wondering why nailed relations could be exceptions.
Conversely why must RelationCacheInvalidate() call
RelationFlushRelation() fo
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]]
>
> "Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
> > Doesn't current heap_open() have a flaw that even the first
> > use of a relation in a transaction may cause an error
> > "relation ### modified while in use" ?
>
> Sure,
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]]
>
> > BTW,I sometimes see
> > ERROR: SearchSysCache: recursive use of cache 10(16)
> > under small MAXNUMMESSAGES environment.
> > I'm not sure about the cause but suspicious if sufficiently
> > many system relations are
On Fri, 3 Nov 2000, Hiroshi Inoue wrote:
> PL/pgSQL already prepares a plan at the first execution
> time and executes the plan repeatedly after that.
> We would have general PREPARE/EXECUTE feature in the
> near fututre. IMHO another mechanism to detect plan invali
> dation is needed.
Excellent
"Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
> Doesn't current heap_open() have a flaw that even the first
> use of a relation in a transaction may cause an error
> "relation ### modified while in use" ?
Sure, that was the starting point of the discussion.
>> because that will open us up to fail
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]]
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > 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 ?
> >
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> 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.
That won't do by itself, because that will op
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 dec
Vadim Mikheev wrote:
> > > > In my understanding,locking levels you provided contains
> > > > an implicit share/exclusive lock on the corrsponding
> > > > pg_class tuple i.e. AccessExclusive Lock acquires an
> > > > exclusive lock on the corresping pg_class tuple and
> > > > other locks acquire
> > > In my understanding,locking levels you provided contains
> > > an implicit share/exclusive lock on the corrsponding
> > > pg_class tuple i.e. AccessExclusive Lock acquires an
> > > exclusive lock on the corresping pg_class tuple and
> > > other locks acquire a share lock, Is it right ?
> >
>
"Mikheev, Vadim" wrote:
> > > > I've wondered why AccessShareLock is a short term lock.
> > >
> > > MUST BE. AccessShare-/Exclusive-Locks are *data* locks.
> > > If one want to protect schema then new schema share/excl locks
> > > must be inroduced. There is no conflict between data and
> > > sc
> > > I've wondered why AccessShareLock is a short term lock.
> >
> > MUST BE. AccessShare-/Exclusive-Locks are *data* locks.
> > If one want to protect schema then new schema share/excl locks
> > must be inroduced. There is no conflict between data and
> > schema locks - they are orthogonal.
> >
>
Vadim Mikheev wrote:
> > > in general. What I'm proposing is that once an xact has touched a
> > > table, other xacts should not be able to apply schema updates to that
> > > table until the first xact commits.
> > >
> >
> > I agree with you.
>
> I don't know. We discussed this issue just after
Philip Warner wrote:
> At 15:29 23/10/00 +0900, Hiroshi Inoue wrote:
> >
> >If we have a mechanism to acquire a share lock on a tuple,we
> >could use it for managing system info generally. However the
> >only allowed lock on a tuple is exclusive. Access(Share/Exclusive)
> >Lock on tables would
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> I'm not sure about the use of AccessShareLock in parse-analyze-
> optimize phase however.
That's something we'll have to clean up while fixing this. Currently
the system may acquire and release AccessShareLock multiple times while
parsing/rewriting/pla
Philip Warner <[EMAIL PROTECTED]> writes:
> Only slightly; one interpretation of a table lock is that it locks all of
> the data in the table; and a lock on the pg_class row locks the metadata. I
> must admit that I am having a little difficulty thinking of a case where
> the distinction would be
> > in general. What I'm proposing is that once an xact has touched a
> > table, other xacts should not be able to apply schema updates to that
> > table until the first xact commits.
> >
>
> I agree with you.
I don't know. We discussed this issue just after 6.5 and decided to
allow concurrent s
At 10:45 23/10/00 -0400, Tom Lane wrote:
>Philip Warner <[EMAIL PROTECTED]> writes:
>> Don't we have this ability? What about taking a RowShare lock on the
>> pg_class tuple whenever you read from the table; then requiring schema
>> updates take a RowExclusive lock on the pg_class tuple?
>
>How is
Philip Warner <[EMAIL PROTECTED]> writes:
> Don't we have this ability? What about taking a RowShare lock on the
> pg_class tuple whenever you read from the table; then requiring schema
> updates take a RowExclusive lock on the pg_class tuple?
How is that different from taking locks on the table
At 15:29 23/10/00 +0900, Hiroshi Inoue wrote:
>
>If we have a mechanism to acquire a share lock on a tuple,we
>could use it for managing system info generally. However the
>only allowed lock on a tuple is exclusive. Access(Share/Exclusive)
>Lock on tables would give us a restricted solution about
Tom Lane wrote:
> Philip Warner <[EMAIL PROTECTED]> writes:
> > At 01:01 23/10/00 -0400, Tom Lane wrote:
> >> (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.)
>
> > A little OT, but the above
At 01:37 23/10/00 -0400, Tom Lane wrote:
>
>What I'm proposing is that once an xact has touched a
>table, other xacts should not be able to apply schema updates to that
>table until the first xact commits.
Totally agree. You may want to go further and say that metadata changes can
not be made whi
Philip Warner <[EMAIL PROTECTED]> writes:
> At 01:01 23/10/00 -0400, Tom Lane wrote:
>> (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.)
> A little OT, but the above is a useful feature for managi
At 01:01 23/10/00 -0400, Tom Lane wrote:
>(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.)
>
A little OT, but the above is a useful feature for managing data; it's not
common, but the following sequen
Alex Pilosov <[EMAIL PROTECTED]> writes:
> On Mon, 23 Oct 2000, Tom Lane wrote:
>> begin;
>> select * from foo; -- gets AccessShareLock
>> LOCK TABLE foo; -- gets AccessExclusiveLock
>> ...
>> end;
>>
>> this will work currently because the SELECT releases AccessShareLock
>> when done,
On Mon, 23 Oct 2000, Tom Lane wrote:
> begin;
> select * from foo; -- gets AccessShareLock
> LOCK TABLE foo; -- gets AccessExclusiveLock
> ...
> end;
>
> this will work currently because the SELECT releases AccessShareLock
> when done, but it will deadlock if S
On Mon, 23 Oct 2000, Alex Pilosov wrote:
> On Mon, 23 Oct 2000, Tom Lane wrote:
>
> > when done, but it will deadlock if SELECT does not release that lock.
> >
> > That's annoying but I see no way around it, if we are to allow
> > concurrent transactions to do schema modifications of tables tha
Alex Pilosov <[EMAIL PROTECTED]> writes:
> I might be in above my head, but maybe this is time for yet another type
> of lock?
Wouldn't help --- it's still a deadlock.
regards, tom lane
On Mon, 23 Oct 2000, Tom Lane wrote:
> when done, but it will deadlock if SELECT does not release that lock.
>
> That's annoying but I see no way around it, if we are to allow
> concurrent transactions to do schema modifications of tables that other
> transactions are using.
I might be in above
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 m
I think this happens after I create/modify tables which reference this
table. This is spontaneous, and doesn't _always_ happen...
Anything I could do next time it craps up to help track the problem down?
-alex
CREATE TABLE "customers" (
"cust_id" int4 DEFAULT nextval('customers_cus
Alex Pilosov <[EMAIL PROTECTED]> writes:
> I'm having the error 'relation modified while in use' fairly
> often. It is the same relation that's always giving a problem.
Hmm, could we see the full schema dump for that relation?
(pg_dump -s -t tablename dbname will do)
If you are not actively mod
34 matches
Mail list logo
