Re: found xmin from before relfrozenxid on pg_catalog.pg_authid
От | Andres Freund |
---|---|
Тема | Re: found xmin from before relfrozenxid on pg_catalog.pg_authid |
Дата | |
Msg-id | 20180525220531.43ia22l2d3jspbng@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: found xmin from before relfrozenxid on pg_catalog.pg_authid (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: found xmin from before relfrozenxid on pg_catalog.pg_authid
|
Список | pgsql-hackers |
On 2018-05-25 17:47:37 -0400, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > > Moving discussion to -hackers. Tom, I think you worked most with this > > code, your input would be appreciated. > > Yeah, the assumption in the relcache is that the only part of a nailed > catalog's relcache entry that really needs to be updated intrasession is > the relfilenode mapping. Paging through the changes to relcache.c and vacuum[lazy].c it looks to me like that hasn't been true in a long time, right? > For nailed indexes, we allow updating of some additional fields, and I > guess what has to happen here is that we teach the code to update some > additional fields for nailed tables too. Yea, it seems like we could just get a new version of the pg_class tuple if in the right state, and memcpy() it into place. Not sure if there's any other issues... BTW, and I guess this mostly goes to Alvaro, I don't understand why that code accepts relation->rd_rel->relkind == RELKIND_PARTITIONED_INDEX? That seems like something we'll hopefully never support. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: