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