Re: Isn't init_irels() dangerous ?

Поиск
Список
Период
Сортировка
От Hiroshi Inoue
Тема Re: Isn't init_irels() dangerous ?
Дата
Msg-id 3A414E52.23218812@tpf.co.jp
обсуждение исходный текст
Ответ на Isn't init_irels() dangerous ?  ("Hiroshi Inoue" <Inoue@tpf.co.jp>)
Ответы Re: Isn't init_irels() dangerous ?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Tom Lane wrote:
> 
> "Hiroshi Inoue" <Inoue@tpf.co.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
HEAP_XMIN_INVALID mask for HEAP_MOVED_IN(OFF) tuples.

Regards.
Hiroshi Inoue


В списке pgsql-hackers по дате отправления:

Предыдущее
От: The Hermit Hacker
Дата:
Сообщение: Re: Replication toolkit added to repository
Следующее
От: Hiroshi Inoue
Дата:
Сообщение: Re: Is PQreset() proper ?