Skip site navigation (1) Skip section navigation (2)

Re: Isn't init_irels() dangerous ?

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 <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Isn't init_irels() dangerous ?
Date: 2000-12-21 00:26:58
Message-ID: (view raw or whole thread)
Lists: pgsql-hackers
Tom Lane wrote:
> "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> writes:
> > It seems that init_irels() should be called after
> > InitializeTransactionSystem() was called.
> Can we just swap the order of the RelationCacheInitialize() and
> InitializeTransactionSystem() calls in InitPostgres?  If that
> works, I'd have no objection.

It doesn't work. InitializeTransactionSystem() requires
pg_log/pg_variable relations which are already built in 
RelationCacheInitialize(). A few critical relations
including pg_log/pg_variable are built in RelationCache
Initialize() without touching database. It's OK but
init_irels() touches system tables to build a few
critical index relations. IMHO init_irels() should
be separated from RelationCacheInitialize().

In the meantime,I have another anxiety. init_irels()
(RelationCacheInitialize()) seems to be called while 
Locking is disabled. This seems to mean that init_irels()
could access to system tables even when they are in
vacuum. HeapTupleSatisfiesXXXX() doesn't seem to take
such cases into account except HeapTupleSatisfiesDirty().
HeapTupleSatisfiesXXXX() sets HEAP_XMIN_COMMITTED or

Hiroshi Inoue

In response to


pgsql-hackers by date

Next:From: Hiroshi InoueDate: 2000-12-21 03:42:35
Subject: Re: Is PQreset() proper ?
Previous:From: The Hermit HackerDate: 2000-12-20 23:51:38
Subject: Re: Replication toolkit added to repository

Privacy Policy | About PostgreSQL
Copyright © 1996-2015 The PostgreSQL Global Development Group