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 ?
|
Список | 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 по дате отправления: