Re: [HACKERS] WAL logging problem in 9.4.3?
От | Kyotaro Horiguchi |
---|---|
Тема | Re: [HACKERS] WAL logging problem in 9.4.3? |
Дата | |
Msg-id | 20200127.150818.232645484356723781.horikyota.ntt@gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] WAL logging problem in 9.4.3? (Noah Misch <noah@leadboat.com>) |
Список | pgsql-hackers |
By the way, the previous version looks somewhat different from what I thought I posted.. At Sun, 26 Jan 2020 20:57:00 -0800, Noah Misch <noah@leadboat.com> wrote in > On Mon, Jan 27, 2020 at 01:44:13PM +0900, Kyotaro Horiguchi wrote: > > > The purpose of this loop is to create relcache entries for rels locked in the > > > current transaction. (The "r == NULL" case happens for rels no longer visible > > > in catalogs. It is harmless.) Since RelationIdGetRelationCache() never > > > creates a relcache entry, calling it defeats that purpose. > > > RelationIdGetRelation() is the right function to call. > > > > I thought that the all required entry exist in the cache but actually > > it's safer that recreate dropped caches. Does the following works? > > > > r = RelationIdGetRelation(relid); > > + /* if not found, fetch a "dropped" entry if any */ > > + if (r == NULL) > > + r = RelationIdGetRelationCache(relid); > > if (r == NULL) > > continue; > > That does not materially change the function's behavior. Notice that the > function does one thing with "r", which is to call RelationClose(r). The > function calls RelationIdGetRelation() for its side effects, not for its > return value. ..Right. The following loop accesses relcache hash directly and no need for storing returned r to the array rels.. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: